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Chapter  1 

Introduction 


This  report  documents  the  results  of  the  SSIIS  project  (Ship  Structural  Integrity  Information 
System)  are  documented.  The  SSIIS  project  is  a  one-year  project  sponsored  by  the  U.S.  Coast 
Guard  Research  k.  Development  Center  through  the  National  Maritime  Enhancement  Institute  of 
the  Maritime  Administration  (MARAD).  The  SSIIS  project  was  initiated  by  the  Department  of 
Naval  Architecture  k.  Offshore  Engineering  at  the  University  of  California  at  Berkeley  in  September 
1993. 

The  SSIIS  project  had  two  main  objectives: 

•  Development  and  documentation  of  standards  for  the  development  of  a  comput¬ 
erized  Ship  Structural  Integrity  Information  System  for  tank  ships. 

•  Demonstration  of  the  application  of  these  standards  with  a  prototype  PC  based 
database  system. 

With  the  development  of  advanced  database  technology  and  the  availability  of  powerful  and 
economic  computer  systems  and  storage  capacity  it  has  become  possible  to  develop  an  integrated 
database  system  for  ships.  Based  on  the  structure  and  complexity  of  the  task,  it  is  necessary  to  use 
a  modular  concept  that  allows  the  individual  development  and  implementation  of  each  module. 

The  Ship  Structure  Committee  has  funded  a  study  to  establish  a  procedure  for  development 
of  Marine  Structural  Integrity  Programs  (MSIP)  for  commercial  ships,  with  particular  focus  given 
to  tankers,  [1].  The  aim  was  to  adopt  a  procedure  similar  to  the  Airframe  Structural  Integrity 
Program  (ASIP)  established  by  the  U.S.  Air  Force  and  the  Federal  Aviation  Agency. 

As  part  of  the  MSIP  study,  the  general  information  structure  governing  all  aspects  of  tanker 
design,  construction  and  operation  has  been  outlined.  This  structure  is  shown  in  Fig.  1.1). 

The  SSIIS  project  uses  this  structure  as  a  starting  point  for  the  development  of  a  general  ship 
information  database  system.  The  data  contents  of  the  different  modules  shown  in  Fig.  1.1)  is 
defined  in  more  detail.  The  main  emphasis  is  given  to  the  Inspection  module.  For  this  module, 
the  necessary  database  structure  is  developed  and  used  for  the  application  prototype  created  as 
part  of  the  SSIIS  project. 

Chapter  2  documents  the  need  for  a  general  ship  information  system  and  describes  important 
components  of  this  system. 

Largely  due  to  the  U.S.  Coast  Guard  requirement  that  makes  it  mandatory  for  tank  ship 
operators  to  submit  Critical  Area  Inspection  Plans  (CAIP)  for  each  vessel  based  on  the  results 
of  structural  surveys,  several  database  systems  have  been  developed  to  archive  and  analyse  the 
results  of  crack  and  corrosion  surveys.  The  underlying  concepts  of  these  systems  have  to  be 
evaluated  in  order  to  make  recommendations  for  a  more  general  system.  In  addition,  based  on 
the  user  experience  with  these  database  systems,  it  is  possible  to  compare  different  data  input 
and  visual  representation  techniques.  Chapter  3  documents  existing  database  systems,  evaluates 
performance  characteristics  and  makes  recommendations  for  an  improved  system. 
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Aside  from  its  use  to  store  and  document  the  inspection  results,  the  Ship  Structural  Integrity 
Information  System  is  intended  to  contain  all  relevant  vessel  information  resulting  from  design, 
construction,  inspection,  maintenance  and  operations.  This  will  allow  it  to  use  the  SSIIS  as  the 
information  source  for  different  analysis  applications,  thus  eliminating  the  need  for  multiple  data 
entry.  In  addition,  the  information  about  vessel  operations  will  give  operators  better  flexibility 
in  scheduling  and  can  result  in  optimized  performance  characteristics.  Chapter  4  documents 
the  information  needs  of  different  analysis  applications,  lists  the  information  available  from  vessel 
operations  and  describes  ongoing  efforts  for  vessel  computerization,  vessel  scheduling  and  data 
management  by  various  operators. 

Chapter  5  documents  the  CAIP  requirements  as  defined  by  the  U.S.  Coast  Guard.  CAIP 
reports  submitted  to  the  U.S.  Coast  Guardby  different  operators  have  been  analysed  to  determine 
the  differences  in  format  and  information  contents.  Based  on  this  analysis  and  on  the  experience 
of  USCG  inspectors  a  desired  format  is  introduced  that  will  be  used  as  an  output  definition  for 
the  SSIIS  prototype  development. 

In  order  to  define  the  scope  and  information  content  of  the  system,  it  is  necessary  to  determine 
the  anticipated  usage  of  the  database.  This  decision  involves  the  investigation  of  the  data  needs 
of  operators,  class  societies  and  regulatory  agencies.  In  addition,  the  information  contents  of 
various  analysis  software  has  to  be  recognized.  Chapter  6  outlines  the  characteristics  of  the  Ship 
Structural  Integrity  Information  System.  This  outline  will  be  used  to  define  the  different  data 
modules  and  develop  the  prototype  application. 

It  is  one  of  the  objectives  of  the  SSIIS  project  to  design  and  implement  an  application  prototype 
that  can  be  used  to  store  inspection  and  survey  results  and  generate  Critical  Area  Inspection  Plans. 
The  prototype  will  use  the  CAIP  format  developed  based  on  the  analysis  of  existing  CAIP  reports. 
Chapter  7  documents  the  prototype  development. 

Chapter  8  concludes  this  report,  summarizes  the  development  and  makes  recommendations 
for  future  development. 
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Marine  Structural  Integrity  Programs 

MSIP 

Information  System 


Figure  1.1:  MSIP  -  Vessel  Information  Structure 


Chapter  2 

The  Need  for  Integrated  Ship 
Information  Systems 


2.1  Reasons  for  Vessel  Information  System 

2.1.1  General  Considerations 

In  recent  years,  several  research  efforts  and  development  projects  have  been  conducted  with  the  aim 
to  develop  and  implement  database  systems  to  store,  manipulate  and  analyse  the  information  that 
is  gathered  during  the  operating  of  commercial  vessels.  In  particular,  most  of  these  efforts  have 
concentrated  on  oil  tankers  due  to  regulatory  requirements  and  the  specific  structural  configurations 
that  require  periodic  inspections  resulting  in  large  amounts  of  survey  data. 

In  addition,  it  is  important  for  tanker  owners  and  operators  to  have  immediate  access  to 
general  ship  specific  information  for  both  the  day  to  day  operations  and  repair  and  maintenance 
procedures. 

Due  to  the  disproportionally  high  number  of  fatigue  cracks  found  in  vessels  operating  on  the 
Trans- Alaska  Pipeline  Service  (TAPS)  trade  route,  the  U.S.  Coast  Guard  requires  a  Critical  Area 
Inspection  Plan  (CAIP)  for  these  vessels.  The  CAIP  for  each  vessel  has  to  specify  the  methods 
used  by  vessel  operators  for  the  documentation  and  tracking  of  structural  failures,  [16]. 

Each  CAIP  will  contain  detailed  information  on  the  vessel’s  fracture  history,  corrosion  control 
systems  and  previous  repairs.  In  addition  the  CAIP  requires  operators  to  document  trends  in 
the  occurence  of  fatigue  and  corrosion  incidents.  The  plan  has  to  be  updated  yearly  to  include 
the  most  recent  survey  data  for  the  determination  of  the  critical  areas.  These  requirements  will 
therefore  result  in  a  large  amount  of  data  that  has  to  be  managed,  which  is  most  easily  done,  if 
the  vessel  and  survey  information  is  contained  in  a  database. 

The  International  Association  of  Classification  Societies  (lACS)  has  recently  published  a  set 
of  rules  governing  the  conduct  of  surveys  for  existing  vessels,  (Enhanced  Survey  Rules  for  Existing 
Vessels),  [21].  The  document  is  partly  based  on  recommendations  issued  by  the  International 
Maritime  Organization  (IMO)  and  the  guidance  manuals  for  tanker  inspections  published  by  the 
Tanker  Structure  Cooperative  Forum,  [36],  [37]. 

The  lACS  document  requires  shorter  inspection  intervals  for  uncoated  ballast  tanks  and  makes 
it  the  owners/operators  responsibility  to  provide  detailed  information  related  to  crack  and  corro¬ 
sion  survey  results  including  trends  and  damage  statistics.  These  guidelines  are  enforced  by  the 
American  Bureau  of  Shipping  (ABS)  for  U.S.  flag  vessels  as  of  January  1,  1993. 
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2.2  The  Fatigue  Problem 

Fig.  (2.1)  shows  a  schematic  view  of  the  Fatigue  Problem  And  the  related  procedures  necessary  for  an 
effective  prevention  and  control  of  fatigue  damage.  In  addition  the  possible  data  exchange  between 
the  different  areas  (information  Management,  Load  Information  and  Analysis)  is  shown. 

In  general,  the  storage  of  analysis  results  in  databases  and  the  retrieval  of  input  parameters 
from  databases  is  a  very  desirable  development  that  will  lead  to  more  efficient  software  tools. 

Regularly  scheduled  inspection  and  maintenance  operations  result  in  a  large  amount  of  survey 
data  (both  for  corrosion  and  cracks).  This  data  has  to  be  managed  efficiently.  A  database  that 
contains  general  vessel  information  and  the  results  from  crack  and  corrosion  surveys  can  be  regarded 
as  the  most  effective  method  of  ("information  Management]. 

Systematic  monitoring  methods  of  vessel  response  quantities  e.g.  accelerations,  stresses,  are 
currently  being  developed.  This  information  can  result  in  improved  estimates  of  the  long-term 
loading.  The  estimates  of  the  long-term  loading  introduces  the  largest  uncertainties  into  the 
fatigue  life  evaluation  procedure.  It  will  therefore  be  extremely  beneficial  to  develop  improved 
estimates  of  the  (Load  Information]. 

("Analysis  j  of  fatigue  damage  has  to  be  performed  for  two  cases: 

•  Design:  Modification  of  a  CSD  resulting  in  a  reduced  SCF  value  will  improve  the  fatigue 
life  of  a  CSD.  Constraints  due  to  manufacturing  limitations  and  economic  considerations 
will  influence  the  design  process. 

•  Repair:  In  general,  several  repair  alternatives  are  available  for  cracks  found  in  CSD.  The 
possibilities  range  from  simply  re- welding  to  a  complete  re-design  of  the  detail.  The  choice 
of  the  repair  method  can  be  based  on  an  economic  optimization  approach. 

The  I  Design  I  of  CSD  can  be  improved  by  using  Damage  Statistics  based  on  the  crack  survey 
information  contained  in  the  database.  The  Design  SCF  Values  that  are  calculated  during  the 
design  of  a  CSD  can  be  included  in  the  database.  This  makes  these  SCF  values  directly  available 
for  the  Repair  case  of  a  CSD. 

Including  the  calculated  SCF  values  in  the  database  will  gradually  result  in  a  catalog  of  SCF 
values  reducing  the  number  of  finite  element  analyses  to  be  performed  for  both  the  Design  and 

the  Repair  case. 

The  linkage  of  the  [Analysis]  procedures  to  the  [information  Management]  will  therefore 
result  in  a  combination  of  the  two  traditional  approaches  to  the  estimation  of  fatigue  life  (SCF 
values  from  finite  element  analysis  or  SCF  values  from  SCF  table  based  on  geometry  parameters). 
In  addition  this  information  linkage  is  one  of  the  requirements  for  the  development  of  a  knowledge 
based  system  for  both  the  design  and  the  repair  of  Critical  Structural  Details. 


2.3  Research  Efforts 


structural  Maintenance  Project  (SMP) 

The  structure  of  the  Fatigue  Problem  shown  in  Fig.  (2.1)  has  been  developed  based  on  the 
experiences  with  the  Structural  Maintenance  Project  (SMP)  ^  .  Within  this  project,  most  aspects 
of  the  Fatigue  Problem  have  been  addressed. 

The  SMP  project  was  a  two-year  international  joint  industry  project  with  two  technical  goals: 

•  To  develop  practical  tools  and  procedures  for  the  analysis  of  proposed  ship  structural  re¬ 
pairs  in  order  to  minimize  time  and  materials  within  the  constraints  of  regulatory  and  class 
requirements  and  prudent  engineering  practices. 

^Structural  Maintenance  Project  for  New  fe  Existing  Ships,  Department  of  Naval  Architecture  k  Off¬ 
shore  Engineering,  University  of  California  at  Berkeley.  1990  -  1992 
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•  To  equip  operators,  classification  societies  and  shipyards  with  powerful,  yet  practical,  ana¬ 
lytical  tools  for  the  assessment  of  corrosion  of  ship  critical  structural  components  and  the 
assessment  of  fatigue  cracking  useful  for  ship  repair  and  maintenance. 

•  To  prepare  guidelines  for  the  cost-effective  design  and  construction  of  lower-maintenance 
ship  structures  which  also  facilitate  future  inspections  and  repairs. 

The  research  efforts  were  organized  into  six  studies: 

Study  1  -  Fatigue  Damage  Evaluations 

Study  2  -  Corrosion  Damage  Evaluations 

Study  3  -  Interaction  of  Details  with  Adjacent  Structure 

Study  4  -  Fatigue  and  Corrosion  Repair  Assessments 

Study  5  -  Durability  Considerations  for  New  &  Existing  Ships 

Study  6  -  Development  of  Software  and  Applications  Examples 

The  developed  software  consists  of  a  ship  information  database  system  (SIMS),  an  interactive 
mesh  generation  module  to  develop  FEM  models  of  Critical  Structural  Details  (CSD),  an  analysis 
module  that  calculates  the  hot-spot  stresses  based  on  a  unit-load  approach,  a  long-term  load 
generation  module  based  on  travel  route  and  ship  characteristics  and  a  fatigue  life  evaluation 
module  that  calculates  fatigue  damage  and  failure  probabilities. 

All  modules  are  linked  through  a  graphical  user  interface  (GUI),  which  makes  the  software 
more  suitable  for  standard  design  and  repair  operations. 

By  automating  the  mesh  generation  and  FEM  analysis  of  CSD  it  is  possible  to  analyse  different 
design  alternatives  and  to  evaluate  the  effect  of  different  repair  alternatives  on  the  hot-spot  stress 
and  thus  the  calculated  long-term  loading  and  the  resulting  fatigue  life. 

The  actual  failure  data  contained  in  the  database  was  used  to  obtain  failure  probabilities 
necessary  to  verify  the  fatigue  analysis  procedure. 

2.4  Intended  Information  Contents 

The  developed  database  structure  can  be  regarded  as  the  core  of  this  system  that  includes  all  areas 
of  design,  operation,  inspection  and  repair  for  vessels.  This  system  should,  among  others,  contain 
the  following  information: 

•  The  original  vessel  design  parameters 

•  Offsets  for  all  frames.  This  information  is  necessary  input  for  ship  motions  programs  and  all 
stability  calculations. 

•  Locations  and  specifications  for  all  tanks 

•  An  electronic  description  of  the  structural  configuration.  This  should  ideally  be  in  a  form 
suitable  for  direct  use  in  a  finite-element  analysis. 

•  The  results  of  all  initial  design  calculations  should  be  stored,  especially  with  regard  to  the 
hot-spot  stresses  in  structural  details.  This  information  is  needed  for  subsequent  fatigue  life 
analyses  and  the  comparison  with  repair  alternatives. 

•  The  vessel’s  voyage  information.  For  each  voyage  the  loading  and  ballast  condition  has  to 
be  included.  In  general,  provisions  have  to  be  made  to  include  all  information  contained  in 
a  vessel’s  deck  log. 

•  Data  obtained  from  the  monitoring  of  the  vessel’s  response  characteristics.  The  amount 
and  type  of  information  has  to  be  determined  in  a  way  that  it  is  possible  to  extract  the 
vessel’s  long-term  loading  from  the  database.  The  development  of  the  database  is  therefore 
intrinsically  connected  to  the  design  and  implementation  of  ship  monitoring  systems. 
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•  Results  from  crack  and  corrosion  surveys.  Location  information  has  to  be  linked  to  the 
structural  configuration. 

•  Repair  information.  The  structural  configuration  of  the  vessel  has  to  be  updated  in  the  case 
that  a  component  is  re-designed.  The  repair  information  should  be  linked  to  the  observed 
and  documented  failures 

The  above  system  has  to  be  developed  in  a  fashion  that  it  can  be  implemented  in  a  modular 
way.  This  is  necessary  since  not  all  possible  users  should  have  access  to  the  complete  system.  A 
core  system,  very  similar  to  the  developed  SIMS  could  be  implemented  as  a  requirement  for  vessel 
operators  and  could  be  used  by  classification  societies  and  regulatory  agencies  as  a  data  source  for 
rule  development  and  research. 

A  more  complete  system  with  some  or  all  of  the  above  outlined  functions  could  be  used  inter¬ 
nally  by  vessel  operators  to  optimize  vessel  design,  operation  and  maintenance. 

Overall,  the  development  of  an  electronic  database  system  for  the  management  of  all  informa¬ 
tion  related  to  the  operation,  inspection,  maintenance  and  repair  of  oil  tankers  will  be  beneficial 
in  reducing  costs  and  improving  the  quality  of  ship  design  and  repair . 
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M -  Database  Update 

- ►  Loading  Information 


Figure  2.1;  Schematic  View  of  the  Fatigue  Problem 
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Chapter  3 


Existing  Ship  Database  Systems 


3.1  Introduction 

Partly  due  to  the  U.S.  Coa^t  Guard  requirement  of  the  implementation  and  maintenance  of  Critical 
Area  Inspection  Plans  and  also  to  facilitate  inspection,  maintenance  and  repair  (IMR)  operations, 
several  database  systems  have  been  developed  that  store  and  evaluate  general  vessel  information 
in  conjunction  with  survey  data.  In  the  following,  several  of  these  systems  are  evaluated  with  the 
purpose  to  determine  the  general  approach,  the  information  contents  and  the  overall  effectiveness. 

Special  regard  is  given  to  the  method  used  to  determine  and  represent  failure  locations  (cracks 
and  corrosion)  within  a  vessel.  The  use  of  graphical  information  is  analysed  to  determine  the 
relation  between  the  cost  for  data  input  to  the  increase  in  information  contents  and  overall  usability. 

The  evaluated  systems  include  the  CATSIR  database  systems  (developed  by  CHEVRON  in  co¬ 
operation  with  OCEANEERING),  ARCO’s  Hull  Fracture  Database  (HFDB),  FracTrac  (developed 
by  MCA  Engineering)  and  SID  (Structural  Inspection  Database,  developed  by  MIL  Systems). 

In  addition,  the  SIMS  (Ship  Information  Management  System)  developed  as  part  of  the  Struc¬ 
tural  Maintenance  Project  for  New  k  Existing  Ships  (SMP)  project  conducted  at  the  Department 
of  Naval  Architecture  k  Offshore  Engineering  at  UC  Berkeley,  is  documented. 

As  part  of  a  one-year  research  effort  to  develop  a  rational  basis  for  defining  corrosion  limits  in 
tankers,  the  structure  of  a  support  database  system  has  been  developed  that  contains  ship  specific 
data  and  inspection  data.  This  database  structure  is  documented  in  section  3.7. 

It  is  the  main  purpose  of  this  review  of  existing  database  systems  to  study  the  different  ap¬ 
proaches  to  archive  and  use  ship  information  and  survey  results  and  to  document  the  applicability 
of  each  system  for  a  future  SSIIS. 

For  each  system,  the  projected  usage  and  overall  programm  philosophy  is  described  and  a 
detailed  description  of  the  program  structure  is  included.  The  benefits  and  disadvantages  of  each 
system  are  summarized  with  special  regard  to  the  requirements  of  a  future  SSIIS. 

Additional  information  about  current  database  efforts  with  respect  to  vessel  reliability,  avail¬ 
ability  and  maintenance  (RAM)  databases  can  be  found  in  [20].  The  background  and  present 
status  of  RAM  databanks  is  described.  Various  national  and  international  RAM  databanks  are 
summarized  with  particular  emphasis  on  the  SRF  data  bank  of  Sweden  and  the  SRIC  data  bank 
of  Japan. 

In  a  different  database  development,  a  selection  guide  for  tankers  of  10,000  deadweight  tons  or 
more  has  been  developed  and  is  updated  and  published  annually,  [35].  The  guide  is  intended  to 
aide  tanker  charterers,  cargo  owners  and  others  involved  with  tankers  in  the  selection  of  tankers 
that  perform  satisfactorily  and  pose  a  minimal  risk  of  casualties. 

A  rating  system  has  been  developed  that  assigns  a  rating  to  each  tanker  based  on  a  set  of 
criteria,  i.e.  casualties,  age,  name  changes,  owner’s  total  losses  and  oil  spills,  classification  society, 
owner,  flag  of  registry,  etc.. 

Of  particular  importance  is  the  inclusion  of  casnalties  and  oil  spills.  Any  future  tanker  database 
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development  has  to  evaluate  the  possible  data  format  to  identify  causes  for  casualties  and  oil  spills. 
This  is  particularly  important  to  evaluate  the  extent  of  human  and  organizational  error  in  tanker 
operations. 


3.2  Database  Theory 

3.2.1  Introduction 

The  storage  and  management  of  information  and  operational  data  has  always  been  one  of  the  most 
important  tasks  for  all  types  of  organizations.  Data  is  in  general  contained  in  a  database.  In  [9], 
the  term  database  is  defined  as 

A  database  is  a  collection  of  stored  operational  data  used  by  the  application  systems 
of  some  particular  enterprise 

It  has  to  be  noted  that  the  storage  method  for  the  data  is  not  defined.  In  the  following  only 
the  development  of  electronic  database  systems  is  outlined. 

A  database  system  is  characterized  by  the  data  model  it  supports.  Early  systems  were  devel¬ 
oped  based  on  the  established  file  system.  These  hierarchical  or  network  models  have  in  general 
low  level  data  manipulation  languages  and  require  users  to  optimize  the  access  to  the  data  by 
carefully  navigating  in  hierarchies  or  networks  [13]. 

Almost  all  of  the  database  systems  developed  over  the  past  few  years  are  based  on  the  rela¬ 
tional  model.  In  addition,  almost  all  current  database  research  is  also  based  on  relational  ideas. 
Many  non-relational  systems  are  often  described,  for  commercial  purposes,  as  supporting  relational 
features.  Currently,  the  relational  model  is  the  single  most  important  development  in  the  entire 
history  of  the  database  field,  [9]. 

3.2.2  The  Relational  Model 

The  relational  model  was  introduced  by  E.F.  Codd  in  1970,  [4],  including  the  following  definition 
of  the  model’s  first  objectives: 

•  To  allow  a  high  degree  of  data  independence.  The  application  programs  must  not  be  affected 
by  modifications  to  the  internal  data  representation,  particularly  by  the  changes  to  file 
organizations,  record  orderings,  and  access  paths. 

•  To  provide  substantial  grounds  for  dealing  with  data  semantics,  consistency,  and  redundancy 
problems. 

In  a  relational  system  data  is  perceived  by  the  user  as  two-dimensional  tables  or  relations.  A 
relation  is  defined  in  [13]  as 

Subset  of  the  Cartesian  product  of  a  list  of  domains  characterized  by  a  name 

where  a  domain  is  the  set  of  possible  atomic  data  items.  A  relation  contains  a  time- variant  number 
of  unique  records.  Each  record  is  uniquely  defined  by  a  primary  key,  where  the  key  can  consist  of 
a  combination  of  several  data  items.  An  atomic  data  item  is  the  smallest  non-dividable  piece  of 
information. 

Relations  are  manipulated  by  the  use  of  a  set  of  operators  defined  as  relational  algebra  and 
an  assignment  operation.  The  most  important  property  of  each  of  the  algebraic  operations  is  the 
fact  that  the  output  of  each  operation  results  in  another  relation.  In  the  original  definition,  Codd 
[6]  defined  eight  operators,  two  groups  of  four  each.  One  group  contains  the  operations  union, 
intersection,  difference  and  Cartesian  product  and  the  other  group  consists  of  the  special 
relational  operations  select  project,  join  and  divide. 

The  fundamental  intent  of  relational  algebra  is  to  allow  the  writing  of  expressions  for  data 
retrieval,  updating,  the  definition  of  access  rights  and  many  other  possible  applications. 
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3.2.3  Database  Design:  Normalization  Theory 

While  the  relational  model  has  led  to  the  development  of  powerful  database  systems,  it  does  not  free 
the  user  from  the  task  of  defining  the  database  structure  and  organizing  the  required  information 
content  into  different  relations. 

A  badly  designed  database  structure  can  lead  to  data  inconsistencies  due  to  data  reduncancy, 
i.e.  the  same  information  is  stored  in  several  places. 

Normalization  Theory  has  been  developed  to  formalize  the  requirements  for  an  effective  database 
design.  Originally,  Codd  defined  the  first,  second  and  third  normal  form  (INF,  2NF,  3NF),  [5]. 
Later  the  third  normal  form  was  re-defined  as  the  Boyce-Codd  normal  form  (BCNF),  [7]  and  a 
fourth  (4NF)  and  fifth  (5NF)  normal  form  were  proposed,  [11], [12]. 

The  definition  of  the  different  normal  forms  is  intended  to  serve  as  guidelines  for  the  design 
of  efficient  databases.  A  relation  is  only  required  to  be  in  the  first  normal  form  (INF).  The  first 
normal  form  (INF)  requires  that  a  relation  only  contains  atomic  values. 

Definitions  for  the  higher  normal  forms  are  given  in  [13],  [9].  In  general  it  is  desirable  to  develop 
relations  that  satisfy  the  conditions  of  the  higher  normal  forms.  However,  for  a  particular  database 
design  it  is  possible  that  a  relation  that  is  not  of  a  higher  normal  form  can  be  advantagous. 

3.3  CATSIR  -  Computer  Aided  Tanker  Structures  Inspec¬ 
tion  Sz  Repair 

3.3.1  Overview 

Chevron  Shipping  Inc.  in  cooperation  with  OCEANEERING  -  Solus  Schall  has  developed  and 
implemented  CATSIR,  a  database  system  for  the  data  management  of  general  vessel  information  in 
combination  with  the  results  from  structural  surveys,  in  particular  crack  and  corrosion  information. 
CATSIR  (Computer  Aided  Tanker  Structures  Inspection  &  Repair)  is  described  in  [38]. 

CATSIR  consists  of  two  components,  a  database  part  and  a  customized  AutoCad^^  drafting 
program. 

•  The  database  is  used  to  store  all  relevant  information.  If  it  is  used  as  a  stand-alone  appli¬ 
cation,  the  information  related  to  the  location  of  corrosion  gaugings  and  crack  occurrences 
and  the  description  of  the  crack  type  are  entered  using  the  frame  numbers  and  different  code 
words. 

•  The  AutoCad^^  part  allows  it  to  post  the  location  information  directly  on  the  construction 
drawing.  In  addition  the  AutoCad^^  module  is  used  to  enter  repair  information  such  as 
areas  for  steel  renewal  and  coatings.  This  information  is  transferred  back  into  the  database 
for  processing. 

3.3.2  Development  History 

CATSIR  has  been  developed  to  be  used  for  data  storage  and  as  a  tool  for  the  repair  and  maintenance 
process.  The  original  development  has  been  started  in  1986.  CATSIR  1.0  contained  a  database 
and  an  AutoCad^-^  module  and  was  intended  to  facilitate  repair  and  maintenance  procedures. 

In  the  second  version  of  CATSIR  (CATSIR  2.0),  the  results  of  crack  and  corrosion  susrveys  were 
included  in  the  database.  The  format  for  the  database  module  that  contains  the  crack  information 
has  been  developed  in  cooperation  with  the  Structural  Maintenance  Project  for  New  &  Existing 
Ships  (SMP)  conducted  at  the  Department  of  Naval  Architecture  and  Offshore  Engineering  at  the 
University  of  California  at  Berkeley,  [32]. 

The  main  focus  of  the  cooperation  was  the  representation  of  fatigue  crack  types  and  location 
without  the  use  of  graphical  illustrations.  This  has  resulted  in  a  set  of  keywords  that  represent  the 
crack  location  and  the  type  of  detail. 
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CATSIR  3.0  includes  a  modified  Defects  module.  The  crack  and  corrosion  information  that  is 
entered  in  the  database  is  directly  transferred  to  the  AutoCad^-^  module.  Only  the  location  has 
to  be  entered  using  a  pointing  device  (mouse).  In  addition,  some  data  analysis  capabilities  are 
included  that  allow  it  to  plot  average  corrosion  rates  and  crack  distributions. 


3.3.3  CATSIR  3.0  -  Program  Capabilities 

CATSIR  (Computer  Aided  Tanker  Structures  Inspection  and  Repairs)  is  a  program  developed  for 
recording  and  manipulating  inspection  and  repair  data  for  tanker  structures.  CATSIR  links  a 
database  management  system  with  a  customized  AutoCad^^  drafting  program  to  allow  users  to 
display  information  either  on  drawings  or  in  a  report. 

According  to  information  provided  by  Solus  Schall,  [28]  and  based  on  the  evaluation  of  the 
demonstration  copy  of  CATSIR  3.00,  the  system  is  intended  to 

•  ImprovG  gauging  team  efficiency  by  eliminating  manual  drafting  and  field  reports  and 
by  reducing  preparation  time  for  the  final  report 

•  Enhance  the  efficiency  and  quality  of  inspections  through  assistance  with  CAIP  pro¬ 
grams,  improved  communications  between  home  office  and  gauging  team  and  through  quick 
identification  of  future  trouble  areas. 

•  Improve  repair  planning  productivity  by  eliminating  manual  writing  of  steel  specifi¬ 
cations,  manual  calculations  of  steel  weight  and  coating  areas,  manual  drafting  of  repair 
drawings  and  through  quick  updates  of  repair  specifications  /  drawings  in  the  field. 

According  to  Solus  Schall,  [28] ,  CATSIR  can  be  used  in  various  stages  of  a  vessel  s  maintenance 
cycle  with  the  main  applications  identified  as  follows: 

Recording  of  data  during  a  voyage  inspection  and  generating  a  survey  report 

No  need  for  drafting  of  drawings  since  the  structural  AutoCad^^  files  are  always  accessible  in 
CATSIR.  The  use  of  CATSIR  eliminates  draft  report  production.  The  ability  to  send  the  CATSIR 
data  electronically  to  the  home  office  is  possible  on  many  ships  and  can  considerably  improve  the 
information  flow  relating  to  an  inspection. 

Preparation  of  steel  repair  specifications  for  periodic  overhauls 

Steel  and  coatings  can  be  specified  on  CATSIR  drawings  and  steel  weights  and  coating  areas 
are  calculated  automatically.  If  the  inspection  information  and  maintenance  history  is  stored  in 
CATSIR,  all  information  needed  for  preparing  the  specification  is  readily  available.  The  CATSIR 
drawings  and  reports  can  then  be  produced  and  attached  to  the  repair  specification. 

Reporting  of  inspection  and  repair  data  during  a  periodic  overhaul 

The  steel  repairs,  coating  work,  and  installed  anodes  can  be  directly  entered  in  CATSIR  which 
will  automatically  calculate  total  steel  weights,  coating  areas,  and  the  total  number  of  anodes. 
This  will  greatly  reduce  the  bookkeeping  associated  with  structural  repairs. 

Preparation  of  U.S.  Coast  Guard  Critical  Area  Inspection  Plans  (CAIP) 

CATSIR  offers  an  excellent  means  of  storing  and  retrieving  the  data  required  by  the  U.S.  Coast 
Guard  for  their  Critical  Area  Inspection  Plans  (CAIP).  CATSIR  is  able  to  record  data  on  fractures 
and  repairs  and  is  easily  updated  after  each  inspection. 

In  order  to  use  the  graphical  features  of  CATSIR  it  is  necessary  to  implement  all  construction 
drawings  in  the  form  of  AutoCad^^  drawings.  For  the  case  that  the  system  is  used  for  both  data 
management  and  repair  planning  and  documentation  the  considerable  expense  for  the  preparation 
of  these  AutCad  drawing  can  be  justified. 
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As  a  most  recent  development,  EXXON  has  purchased  the  database  part  of  CATSIR  to  be 
used  for  the  documentation  and  management  of  vessel  data  and  survey  results. 

3.3.4  CATSIR  3.0  -  Program  Structure 

The  CATSIR  database  system  is  menu-driven.  The  Main  Menu  contains  the  following  five  items. 

1.  Vessel  Information 

2.  T.I.P.  (Technical  Information  Pool) 

3.  Tank  Voyage  Log 

4.  Library  Maintenance 

5.  System  Administration 

The  functionality  of  each  item  is  summarized  in  the  following  sections. 

•  Vessel  Information:  The  vessel  information  module  is  the  heart  of  the  CATSIR  program 
and  is  the  access  point  to  the  twelve  available  CATSIR  sub-modules: 


Vessel  Information 
Vessel  History 
Tank  Information 
Drawing  Log  k  AutoCad^^ 
Survey  (Inspection) 
Anode  Data 
Coating  Data 
Crack  Survey 
Gauging  -  Wall  Thickness 
Photographic  Log 
Pitting  Survey 
Renewal  Records 


The  information  contents  for  each  of  these  sub-modules  is  listed  in  Appendix  A. 

•  T.I.P.  (Technical  Information  Pool):  The  T.I.P.  module  is  simply  a  user-defined  help 
system  designed  to  exist  alongside  the  formal  CATSIR  help  system.  From  this  module  any 
tip  (typically  relating  to  the  system  or  the  inspection  control)  may  be  entered  thus  allowing 
the  users  to  share  usage  experience  and  improve  overall  system  performance. 

Each  entry  in  the  T.I.P.  contains  the  following  information: 

—  Keyword 
—  Date 

-  Author 

-  Source 

-  Comment  (any  length,  contains  the  actual  information 

•  Tank  Voyage  Log:  The  tank  voyage  log  is  an  isolated  module  designed  to  store  basic  data 
on  the  conditions  endured  by  any  tank  being  monitored.  The  system  provides  data  that 
may  be  used  to  predict  the  tank’s  condition  based  on  its  use. 

The  information  contained  in  the  tank  voyage  log  is  listed  in  Appendix  A. 
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•  Library  Maintenance:  Many  of  the  fields  in  the  various  categories  in  CATSIR  are  val¬ 
idated  automatically,  some  fields  are  checked  against  standard  user-defined  validation  li¬ 
braries,  thus  enforcing  consistent  data  entry.  Library  maintenance  is  the  module  where  the 
system  administrator  controls  these  validation  data-tables. 

The  Library  Maintenance  module  contains  the  following  entries: 


Vessel  Owner  Library 
Ship  Builder  Library 
Shipyard  Library 
Classification  Society 
Inspection  Equipment 
Inspection  Company 
U.T.  Technicians 
Steel  Type 
Product  Number 
Color 

Coating  Type 
Surface  Discontinuity 
Member 
IGS  Source 

Survey  /  Inspection  Typ 
Crack  Cause 
Zone  Definition 
Repair  Type _ 


•  System  Administration:  All  housekeeping  tasks  relating  to  the  database  management 
are  undertaken  in  this  module. 

The  following  tasks  can  be  performed  within  the  system  administration  module: 


Exit 

Password  Maintenance 
Regenerate  System 
Change  to  Multi/Single  User 
Printer  Control 
Print  User  Documentation 


3.3.5  User  Experience 

The  development  of  CATSIR  has  been  sponsored  by  Chevron  Shipping.  The  system  has  been  used 
by  Chevron  as  part  of  the  vessel  maintenance  and  repair  operations.  The  experience  of  engineers 
and  inspectors  with  CATSIR  has  strongly  influenced  the  development  of  the  most  recent  version, 
CATSIR  3.0. 

Informative  meetings  at  Chevron  Shipping  and  the  use  of  a  demonstration  copy  of  CATSIR 
3.0  have  resulted  in  the  following  information: 

•  Currently,  42  vessels  are  included  in  the  database.  About  500  AutoCad^^  drawings  are 
available  per  vessel.  A  total  of  about  900  mB  of  storage  capacity  is  necessary  for  a  total  of 
18800  AutoCad^^  drawings. 
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•  Depending  on  the  vessel  class  and  the  number  of  drawings  per  class,  it  costs  between  $15,000 
and  $20,000  to  prepare  the  AutoCad^^  drawings  for  one  vessel  class  and  include  them  into 

CATSIR. 

•  At  the  present  time,  the  AutoCad^^  drawings  for  the  42  vessels  currently  entered  into 
CATSIR  are  stored  on  an  optical  disk  and  can  be  accessed  through  the  implemented  Local 
Area  Network  (LAN). 

•  CATSIR  3.0  contains  some  analysis  capabilities  that  allow  it  to  calculate  and  display  average 
corrosion  rates  for  different  areas  in  the  vessel.  It  is  also  possible  to  create  charts  that  show 
the  distribution  of  different  crack  types.  However,  these  analysis  and  graphing  capabilities 
are  not  flexible  enough  to  accomodate  both  the  day-to-day  needs  and  more  advanced  research 
to  determine  trends  and  causes  for  failures. 

3.3.6  CATSIR  -  Summary 

CATSIR  3.0  is  primarily  designed  to  contain  the  results  of  structural  surveys  and  to  facilitate  the 
repair  and  maintenance  operations.  It  incorporates  graphical  representations  of  the  ship  structural 
components  using  AutoCad^^. 

The  incorporation  of  the  structural  drawings  in  a  vessel  database  can  be  used  as  an  example  for 
the  future  implementation  of  SSIIS.  The  necessary  amount  of  storage  space  will  make  it,  however, 
necessary  to  improve  the  data  storage  methods. 

Presently,  CATSIR  can  be  easily  improved  to  produce  Critical  Area  Inspection  Plans  that  meet 
the  developed  format.  Additional  data  analysis  routines  have  to  be  implemented  that  facilitate  the 
observation  of  trends.  In  addition,  the  classification  of  critical  inspection  areas  has  to  be  included 
in  CATSIR. 

3.4  HFDB  -  Hull  Fracture  DataBase 

3.4.1  Overview 

A  graphical  database  for  hull  fracture  reports  has  been  developed  by  Aerohydro,  Inc.  (AHI)  for 
ARCO  Marine,  Inc.  (AMI).  The  database  is  described  in  detail  in  [23] 

The  purpose  of  HFDB  is  the  establishment,  maintenance  and  utilization  of  a  graphics-oriented 
database  of  structural  fracture  data  from  the  AMI  fleet  of  crude  oil  tankships.  Using  HFDB  enables 
the  user  to  discern  and  explore  patterns  of  fracture  experience,  which  may  lead  to  improved  design, 
maintenance,  and  inspection  procedures  and  to  reduced  risk  of  structural  failures  in  future  vessel 
operations. 

Data  is  entered  graphically  through  the  use  of  graphics  tablets  allowing  fracture  locations  to 
be  entered  from  fracture  report  sheets.  The  system  uses  a  general  coordinate  system  to  represent 
fracture  locations.  For  each  vessel  class  the  construction  drawings  of  the  different  frames  are  stored 
in  the  database  in  a  graphical  format  and  are  used  to  display  the  fracture  information. 

Due  to  the  defined  purpose  of  the  database  system  the  description  of  the  location  and  the 
nature  of  the  fracture  incidents  does  not  include  a  precise  definition  of  the  fracture  location  in 
the  particular  structural  detail.  The  fracture  information  contained  in  the  database  can  therefore 
not  directly  be  used  to  verify  or  calibrate  the  results  from  fatigue  damage  or  fracture  mechanics 
calculations. 

ARCO  Marine  Inc.  is  using  HFDB  to  monitor  and  assess  hull  fractures  in  its  fleet  of  ten  crude 
oil  tankers  in  the  Alaska  to  West  Coast  trade.  Use  of  the  database  focuses  ARCO’s  fracture  control 
efforts  which  include  inspections,  analyses,  and  modifications. 

3.4.2  HFDB  -  Program  Structure 

A  detailed  summary  of  the  program  structure  and  the  data  input  method  used  for  HFDB  can  be 
found  in  [23]  and  is  summarized  in  the  following. 
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HFDB  is  a  menu  driven  program.  The  main,  top  level  menu  provides  access  to  the  three 
principal  functions: 

•  Data  Entry 

•  Data  Selection 

•  Display 

The  main  menu  also  provides  access  to  utility  functions  such  a  backing  up  and  restoring  the 
fracture  database  and  deleting  erroneous  fracture  records. 

The  system  is  implemented  as  a  Paradox  implication  Language  (PAL)  program.  This  program 
calls  compiled  programs  written  in  Microsoft©  QuickBASIC  to  perform  graphical  functions  not 
conductive  to  implementation  with  PAL. 

3.4. 2.1  Data  Entry 

Input  to  HFDB  is  initially  entered  by  a  shipyard  surveyor  on  a  paper  form  called  a  Fracture 
Report  Sheet  (FRS).  An  FRS  is  an  8.5”  x  11”  form  with  a  drawing  of  a  particular  structure  in 
a  particular  class  of  ship.  Five  different  types  of  FRS  are  currently  implemented  in  the  HFDB: 

1.  Bulkhead 

2.  Web  Frame 

3.  Bulkhead  /  Web  Frame 

4.  Centerline  Girder 

5.  Longitudinal  Girder  (off-center) 

A  particular  FRS  may  be  unique  or  generic.  Generic  FRS’s  have  a  secondary,  schematic 

drawing  which  allows  the  FRS  to  be  located  in  the  ship. 

Fractures  are  marked  on  the  appropriate  FRS  indicating  the  location  and  the  severity  (length). 
When  a  blank  FRS  has  been  filled  out,  it  becomes  a  Fracture  Report. 

Fracture  reports  (FR)  are  entered  into  HFDB  using  a  graphical  tablet.  For  a  given  FR,  the 
ship  identification,  date  and  the  type  of  FRS  is  entered.  To  enter  a  fracture  requires  the  following 
information: 

1.  A  structural  member  selected  from  a  list  of  structural  members 

2.  A  severity  level 

3.  A  location  on  the  structural  drawing 

Optionally,  a  repair  method  (repair/modify/renew)  and  a  comment  can  be  entered. 

3.4. 2. 2  Data  Selection 

Data  analysis  with  HFDB  requires  the  selection  of  data  subsets.  HFDB  allows  the  selection  of 
data  based  on  ship,  class,  structure  fractured,  severity,  and  date.  In  addition  it  is  also  possible  to 
select  a  particular  FR  or  a  specific  type  of  structure. 

For  experienced  Paradox  users,  there  is  a  provision  to  enter  Paradox,  make  a  selection  using 
all  the  capabilities  of  the  Paradox  query  mechanism,  return  to  HFDB,  and  display  the  selected 
subset. 
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3.4. 2. 3  Graphic  Display 

The  selected  data  subsets  can  be  displayed  in  one  of  three  views.  The  Time  Plot  displays  a 
histogram  of  the  selected  fracture  records  vs.  time  with  the  bars  of  the  histogram  color  coded  for 
severity. 

The  Profile  Display  shows  a  schematic  profile  of  a  ship  below  a  stacked  bar  chart  representing 
the  longitudinal  distribution  of  the  selected  fractures.  Each  bar  is  color  coded  to  represent  the 
occurrence  of  each  severity. 

In  the  Section  View  the  location  of  the  fractures  in  a  selected  section  is  shown.  In  addition  the 
transverse  and  vertical  distribution  of  the  fractures  is  shown. 

Each  display  option  can  be  sent  to  an  attached  PostScript  printer  to  produce  presentation 
quality  output. 

3.4.3  Information  in  Fracture  Database 

The  fracture  database  is  the  core  of  HFDB.  It  contains  one  record  for  each  fracture.  The  following 
information  is  recorded  for  each  fracture: 

•  Fracture  Report  serial  number 

•  Fracture  number  -  within  fracture  report 

•  FRS  number  -  identifies  the  fracture  repotrt  sheet  from  wich  the  data  was  entered 

•  Ship 

•  Vessel  Class 

•  X  -  location  of  fracture 

•  Y  -  location  of  fracture 

•  Z  -  location  of  fracture 

•  Severity 

•  Member  -  chosen  from  a  defined  list  of  structural  members 

•  Disposition  -  Repair,  Modify,  Renew 

•  Year  repaired 

•  Date  entered 

3.4.4  HFDB  -  Summary 

The  Hull  Fracture  DataBase  that  is  currently  used  by  ARCO  has  been  specifically  designed  to 
facilitate  the  storage  and  analysis  of  fractures  in  tank  vessels.  It  includes  options  to  view  the 
distribution  of  different  crack  types  in  the  vessel. 

Most  interesting  is  the  data  input  method  used  to  enter  crack  locations  into  the  database. 
Standardized  templates  are  used  to  record  the  crack  location  in  the  vessel.  Using  a  digitizing 
tablet,  these  location  are  then  transferred  to  the  database. 

HFDB  contains  only  fracture  information.  Additional  general  vessel  data  has  to  be  included 
to  make  it  fully  compatible  with  the  developed  CAIP  standards. 
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3.5  FracTrac 


3.5.1  Overview 

FracTrac  is  a  database  designed  for  the  computerized  tracking  of  vessel  structural  failures.  It  has 
been  developed  by  MCA  Engineering,  Costa  Mesa,  CA  92626,  to  facilitate  the  input  and  storage 
of  cracks  in  structural  details. 

In  1990  and  1991  the  U.S.  Coast  Guard  had  individual  meetings  with  tanker  operators  to 
determine  and  evaluate  the  different  methods  used  to  manage  survey  information  related  to  vessel 
structural  failures.  Based  on  the  outcome  of  this  investigation,  the  U.S.  Coast  Guard  decided  to 
developed  fracture  histories  for  individual  tankers.  •  .  •  j 

In  order  to  facilitate  the  development  of  these  fracture  histories,  MCA  Engineers  initiated 
the  development  of  an  electronic  database  system  that  could  be  used  to  store  and  review  vessel 
structural  failures.  After  an  initial  development  period  of  1  year,  the  system  was  successfully  used 
in  a  field  test  in  Richmond,  CA. 

The  initial  development  of  FracTrac  was  supported  by  West  Coast  Shipping.  In  addition, 
BP  Oil  will  be  using  FracTrac  for  its  tanker  fleet  and  has  asked  MCA  Engineers  to  prepare  the 
necessary  input  data  for  the  vessels.  This  includes  the  development  of  AutoCad  drawings  of 
the  primary  ship  structure.  An  existing  database  that  contains  the  fracture  history  for  the  165,000 
DWT  Atigun  Pass  Class  tankers  will  be  converted  to  FracTrac  in  order  to  have  the  complete 

fracture  histories  of  these  vessels  available  in  one  database. 

According  to  company  information,  FracTrac  has  been  specifically  designed  to  facilitate  the 
preparation  of  Critical  Area  Inspection  Plans  (CAIP)  as  required  by  the  U.S.  Coast  Guard.  The 
possibility  to  have  FracTrac  installed  onboard  of  a  vessel  makes  it  possible  to  review  the  fracture 
history  and  the  distribution  of  fractures  on  the  vessel  prior  to  an  inspection. 

Based  on  the  development  and  operational  experience  with  FracTrac,  MCA  Engineers  is  cur¬ 
rently  developing  additional  modules  that  will  allow  it  to  enter  and  analyse  thickness  gaugings  and 
calculate  corrosion  rates. 


3.5.2  FracTrac  -  Program  Structure 

FracTrac  has  been  developed  for  IBM  PC  compatible  computers  using  the  Microsoft©  Windows^^ 
graphical  user  interface  (GUI).  The  database  has  been  built  using  FoxPro  2.5  database  development 

system  for  Windows^^ .  ,  .  -i 

FracTrac  is  intended  to  provide  a  graphical  display  of  fractures  in  the  ship  structural  details 
in  conjunction  with  detailed  information  about  the  individual  fractures.  In  order  to  achieve  this 
goal,  FracTrac  consists  of  two  inter-related  modules: 

•  Graphical  representation  of  vessel  structural  geometry  using  AutoCad^^  drawings  of  pri¬ 
mary  structural  components. 

•  Fracture  database 

FracTrac  has  been  developed  as  a  one-vessel  system.  All  data  file  and  AutoCad^^  drawing 
naming  conventions  are  designed  to  handle  one  individual  vessel.  In  dayAo-day  operations,  the 
information  for  one  vessel  is  stored  on  an  optical  disk,  which  is  loaded  into  the  system  before 

FracTrac  is  started.  j  j 

If  information  for  a  different  vessel  is  required,  the  old  vessel  data  has  to  be  removed  and  the 

new  vessel  data  is  read  into  the  system  from  its  optical  disk. 

This  information  structure  severely  limits  the  applicability  of  FracTrac  for  multiple  vessel 
configurations.  The  need  to  physically  remove  data  from  the  disk  can  result  in  a  loss  of  data  due 

to  an  operator  error.  •  t  •  + 

The  data  analysis  capabilities  are  also  limited  due  to  this  one-vessel  configuration.  It  is  not 
possible  to  investigate  fractures  in  different  vessels  of  the  same  class  to  identify  trends  and  to 
evaluate  pattern  type  failures. 
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3. 5. 2.1  FracTrac  -  AutoCad^^  Module 

In  order  to  get  a  clear  understanding  about  the  distribution  of  fractures  in  a  vessel,  it  is  necessary 
to  use  a  graphical  representation  of  the  vessel  geometry.  FracTrac  uses  AutoCad^^  to  visualize 
the  ship  structure,  because  of  the  wide  acceptance  of  AutoCad^^  for  Computer  Aided  Design 
purposes. 

As  part  of  the  necessary  input  information  for  a  vessel,  it  is  therefore  necessary  to  generate 
AutoCad^^  drawings  of  the  ship  structure.  The  level  of  visualization  is  dependent  on  the  level  of 
detail  in  the  AutoCad^^  drawings. 

In  order  to  reduce  data  preparation  costs,  one  operator  has  chosen  to  focus  only  on  the  cargo 
block  and  to  prepare  drawings  only  for  primary  structural  components,  i.e.  webframes,  longitudinal 
girders,  bulkheads.  As  a  result  of  this  decision,  it  will  not  be  possible  to  represent  cracks  in 
secondary  or  tertiary  components.  The  location  of  a  crack  in  a  horizontal  girder  or  a  bracket 
connection  can  therefore  be  entered  only  approximately,  which  can  result  in  a  misleading  graphical 
representation. 

Depending  on  the  purpose  for  the  use  of  FracTrac,  this  loss  of  accuracy  might  be  acceptable 
considering  the  significant  cost  benefits  due  to  the  reduced  number  of  AutoCad^^  drawings. 

The  system  is  able  to  show  a  wireframe  view  of  the  vessel  that  includes  the  locations  for  all 
fractures  that  have  been  entered  for  the  vessel.  The  wireframe  view  is  created  by  using  the  outlines 
of  all  frames  and  transverse  bulkheads. 

Since  the  system  uses  a  customized  AutoCad^^  user  interface,  it  is  possible  to  show  individual 
frames  and  structural  components  of  the  vessel.  By  selecting  a  specific  fracture  the  structure  that 
is  linked  to  this  fracture  is  displayed.  This  makes  it  possible  to  quickly  identify  problem  areas  and 
the  associated  structure. 

A  lookup  table  is  created  that  specifies  for  each  AutoCad^^  drawing  the  origin,  the  orientation 
and  the  location(s)  within  the  ship.  This  makes  it  possible  to  have  one  drawing  for  several  locations. 

In  general,  the  ability  of  FracTrac  to  include  AutoCad^^  drawings  to  graphically  represent 
the  ship  structure  makes  the  program  very  useful  to  review  and  quickly  identify  problem  areas. 
The  flexibility  in  the  level  of  detail  in  the  AutoCad^^  drawings  makes  it  possible  to  customize  the 
display  of  the  ship  structure  based  on  the  preferences  and  objectives  of  the  vessel  owner .  A  limited 
representation  of  the  vessel  structure,  e.g.  the  cargo  block  only,  will  significantly  reduce  the  costs 
associated  with  the  preparation  of  the  AutoCad^^  drawings. 

Fractures  are  entered  directly  into  the  structural  drawings.  Each  fracture  is  represented  graph¬ 
ically  with  a  colored  symbol  indicating  the  fracture  class.  The  fractures  are  directly  linked  to  the 
database,  where  additional  information  for  each  fracture  is  entered.  This  includes  the  fracture 
location,  the  nature  of  the  fracture,  and  additional  photos  and  sketches. 

Figs.  (3.1,  3.2)  show  screen  images  of  FracTrac’s  AutoCad^^  module.  The  figures  show  the 
different  structural  views  and  the  representation  of  crack  locations  within  the  structure. 

Fractures  can  only  be  entered  for  structural  components  that  are  represented  in  an  AutoCad^^ 
drawing.  In  the  case  that  a  fracture  is  located  in  a  component  that  is  not  represented,  this  fracture 
has  to  be  entered  in  the  closest  structural  component  that  is  represented  in  an  AutoCad^-''^  drawing. 
This  procedure  can  therefore  result  in  a  graphical  misrepresentation  of  fractures. 

If,  for  example,  fractures  are  found  in  horizontal  girders,  but  no  AutoCad^^  drawings  for  hori¬ 
zontal  girders  are  available  in  FracTrac,  these  fractures  have  to  be  entered  on  the  adjacent  bulkhead 
and  will  therefore  show  in  the  display  as  bulkhead  fractures.  In  the  fracture  database,  however, 
these  fractures  can  be  identified  correctly  as  being  located  in  the  horizontal  girder.  Unfortunately, 
it  is  not  possible  to  determine,  whether  the  AutoCad^^  location  or  the  database  location  is  the 
correct  one. 

3. 5. 2. 2  FracTrac  -  Fracture  Database 

In  conjunction  with  the  graphical  representation  of  the  ship  structure  and  the  fracture  location, 
a  database  is  used  in  FracTrac  to  store  and  manipulate  information  related  to  the  individual 
fractures. 
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The  database  has  been  developed  using  FOXPRO  2.5,  a  Windows^'''^based  database  develop¬ 
ment  system.  The  Windows^'*'^ graphical  user  interface  facilitates  the  use  and  display  of  sketches 
and  photos  and  makes  it  possible  to  seamlessly  integrate  the  AutoCad^-'^  environment  for  the 
graphical  representation  of  the  ship  structure  and  the  fracture  location. 

FracTrac  organizes  the  fractures  according  to  Report  #,  Tag  #  and  Code  #.  This  relates  the 
fractures  both  to  the  AutoCad^^  drawing  and  to  the  survey  report  that  has  been  used  to  enter 
the  fracture  into  the  database. 

The  fracture  location  is  defined  in  two  ways  that  are  not  directly  related  to  each  other.  The 
fracture  is  first  entered  graphically  in  the  AutoCad^^  drawing,  which  at  the  same  time  creates 
a  record  in  the  fracture  database.  Once  a  fracture  is  entered  in  an  AutoCad^^  drawing,  the 
fracture  entry  screen  for  this  new  record  is  opened  to  allow  additional  data  input  for  the  new 
record.  Fig.  (3.3)  shows  this  data  entry  screen.  The  following  information  is  used  to  represent  the 
fracture  location: 

•  Tank  #:  When  the  fracture  record  is  first  opened  based  on  a  fracture  entry  in  an  AutoCad^^ 
drawing,  the  Tank  defaults  to  the  corresponding  tank  #  in  the  AutoCad^^  drawing. 
It  is,  however,  possible  to  change  this  entry,  which  in  turn  will  destroy  the  link  between 
the  AutoCad^^  fracture  location  and  the  fracture  record  location.  It  is  therefore  solely  the 
users  responsibility  to  ensure  data  integrity. 

•  Tank  Location:  The  tank  location  identifies  the  transverse  location  of  a  particular  tank 
(port,  center,  starboard).  This  information  is  also  by  default  obtained  from  the  AutoCad^^ 
drawing,  but  can  also  be  changed  by  the  user. 

•  From  Frame  #  To  Frame  #:  The  two  frame  #’s  identify  the  longitudinal  location  of 
the  fracture.  The  relative  position  of  a  fracture  between  two  frames  can  not  be  accurately 
specified.  The  entry  of  the  frame  #’s  is  also  independent  from  the  location  of  the  fracture 
in  the  AutoCad^^  drawing. 

•  From  Stiffener  To  Stiffener:  The  two  stiffener  #’s  identify  the  vertical  location  of  the 
fracture.  In  praxis,  this  is  only  applicable  for  fractures  in  sideshell  or  longitudinal  bulkhead 
details.  The  stiffener  #’s  are  not  linked  to  actual  coordinates  in  a  general  coordinate  system 
and  can  therefore  not  give  an  accurate  definition  of  the  vertical  position.  In  addition,  the 
relative  location  of  a  fracture  between  two  stiffeners  can  not  be  specified. 

•  Primary  Member:  In  addition  to  the  geometric  location,  the  fracture  location  is  identified 
in  terms  of  the  structural  components.  The  primary  member  details  the  main  structural 
component  in  which  the  fracture  is  located.  Primary  members  are:  deck,  bottom,  sideshell, 
longitudinal  bulkhead,  transverse  bulkhead,  frame,  center  vertical  keel. 

•  Secondary  Member:  This  entry  identifies  the  local  structural  component  that  is  associated 
with  the  fracture.  This  makes  it  possible  to  classify  fracture  and  perform  search  and  analysis 
operations  based  on  local  structural  components.  Secondary  members  are:  plating,  stiffener, 
bracket,  strut,  horizontal  girder. 

•  Tertiary  Member:  This  entry  is  intended  to  identify  the  exact  fracture  location,  or  the 
fracture  origin.  Tertiary  members  are:  web,  flange. 

•  Comment:  In  the  comment  field,  additional  information  about  the  fracture  location,  or 
origin  can  be  entered  as  text. 

In  addition  to  the  described  information,  the  fracture  location  and  type  can  also  be  identified 
through  sketches  and  photos,  which  can  be  a  more  effective  method  to  clearly  document  a  specific 
fracture.  The  only  drawback  in  the  use  of  sketches  or  photos  is  the  amount  of  storage  space  that 
is  necessary.  Sketches  and  photos  are  stored  as  bitmaps,  which  have  a  size  of  about  100  Kb.  The 
use  of  sketches  and  photos  will  therefore  significantly  increase  the  size  of  the  database. 

After  specifying  the  fracture  location,  the  fracture  characteristics  are  described  in  more  detail. 
The  following  information  is  entered  for  each  fracture: 
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•  Class:  Three  classes  of  fractures  can  be  entered.  These  classes  correspond  to  the  U.S.  Coast 
Guard  definition  of  fracture  classes,  see  [15].  The  USCG  class  definitions  are  summarized 
in  section  5.2.1.  This  class  definition  is  used  to  color-code  the  fracture  locations  in  the 
AutoCad^-^  drawing. 

•  Size  in  inches:  The  length  of  the  fracture  is  entered  here. 

•  Repair  Method:  In  order  to  evaluate  the  effectiveness  of  different  repairs,  it  is  nece.ssary 
to  specify  the  repair  method  for  a  fracture.  The  following  repair  methods  can  be  entered: 
re-weld,  renew,  modified. 

•  Type:  The  type  information  is  intended  to  distinguish  between  new  fractures  and  fractures 
in  previously  repaired  locations.  This  information  can  help  to  identify  unsuccessful  repair 
solutions. 

•  Previous  Tag  #,  if  repeated  fracture:  For  fractures  in  previously  repaired  locations,  the 
tag  #  of  the  original  fracture  has  to  be  entered  to  allow  the  construction  of  repair  histories. 

•  Comments:  Comments  with  regard  to  the  fracture  cause,  or  specific  location  or  other  more 
general  remarks  can  be  entered  in  text  form. 

The  database  module  of  FracTrac  does  not  contain  provisions  to  enter  general  vessel  related 
information,  i.e.  LBP,  LOA,  breadth,  draft,  etc..  In  addition,  no  tank  specific  information  can  be 
entered.  This  constitutes  a  significant  drawback  with  regard  to  the  preparation  of  Critical  Area 
Inspection  Plans  (CAIP).  As  part  of  a  CAIP,  general  vessel  information  is  required.  In  order  to 
develop  an  automated  CAIP  report  generating  module,  it  is  necessary  to  have  access  to  the  general 
vessel  information. 

3. 5. 2. 3  FracTrac  -  Reporting  Module 

A  reporting  module  is  currently  being  implemented  by  MCA  Engineers.  This  module  uses  graphical 
displays  to  show  the  general  vessel  layout  including  tank  locations  and  tank  types.  Fig.  (3.4)  shows 
this  reporting  screen.  In  addition  to  the  tank  locations,  a  pie-chart  is  shown  that  identifies  the 
percentage  of  Class  1,  2  and  3  cracks  found  in  the  vessel. 

In  a  second  screen  for  the  inspection  summary,  bar-charts  show  the  number  of  cracks  separately 
for  port,  center  and  starboard  tanks.  This  FracTrac  screen  display  is  shown  in  Fig.  (3.5).  It  is 
possible  to  select  the  display  of  all  fracture  classes  or  only  one  or  two  of  the  three  classes.  This 
makes  it  possible  to  clearly  identify  the  more  severe  fracture  classes. 

The  tank  locations  and  the  general  arrangement  are  obtained  from  a  general  arrangement  plan 
that  is  contained  in  FracTrac  as  an  AutoCad^^  drawing.  The  different  tank  types  are  identified 
through  the  use  of  color-coding. 

The  distribution  of  fractures  over  the  ship  length  can  be  customized  using  different  search  and 
selection  criteria.  It  is  possible  to  select  all  fracture  classes  or  to  show  only  one  or  two  of  the  three 
classes.  In  addition  fractures  can  be  shown  for  individual  tank  types  and  tank  locations. 

The  focus  on  the  three  fracture  classes,  as  defined  by  the  U.S.  Coast  Guard  makes  the  reporting 
module  very  useful  for  the  generation  of  Critical  Area  Inspection  Plan  (CAIP)  reports.  The  use  of 
color  codes  to  identify  the  different  fracture  classes  makes  it  possible  to  obtain  a  very  informative 
overview  over  the  general  vessel  condition. 

3.5.3  FracTrac  -  Summary 

FracTrac  consists  of  a  combination  of  a  customized  AutoCad^^  interface  with  a  Windows^^based 
database  system.  The  software  is  intended  for  the  computerized  tracking  of  vessel  structural 
failures.  According  to  company  information,  FracTrac  can  be  used  for  the  generation  of  Critical 
Area  Inspection  Plan  (CAIP)  reports  as  required  by  the  U.S.  Coast  Guard. 
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Based  on  this  evaluation  of  FracTrac,  it  has  to  be  concluded  that  the  program  can  be  very 
helpful  in  the  generation  of  C  AIP  reports,  but  it  misses  some  important  information  that  is  required 
as  part  of  a  CAIP  report.  In  the  following,  some  of  the  key  features  of  FracTrac  are  commented: 

•  Program  Structure:  The  configuration  of  FracTrac  as  a  one-vessel  application  severely 
limits  the  program  for  general  use.  Reporting  and  analysis  capabilities  for  multiple  vessels  of 
the  same  class  are  not  possible.  The  manual  replacement  of  data  that  is  necessary  in  order 
to  load  a  different  vessel  into  FracTrac  can  result  in  data  losses  or  data  corruption  due  to 
an  operator  error. 

•  AutoCad^^  graphical  display:  The  use  of  AutoCad^^  drawings  to  represent  the  ship 
structure  results  in  a  detailed  representation  of  the  structural  configuration.  Fracture  loca¬ 
tion  can  be  accurately  defined,  if  the  AutoCad^^  drawing  of  the  relevant  structural  com¬ 
ponent  has  been  included  in  the  FracTrac  drawing  library. 

In  cases  were  drawings  of  secondary  or  tertiary  structural  components  have  been  ommitted 
due  to  economic  considerations,  fractures  in  these  components  can  not  be  represented  at  the 
correct  locations. 

•  Fracture  database:  The  database  is  focused  on  the  entry  of  fracture  information  only.  No 
general  ship  information  or  tank  information  can  be  entered.  This  limits  the  database  as  a 
general  tool  for  the  storage  of  vessel  information.  In  addition,  necessary  information  for  the 
generation  of  CAIP  reports  is  not  available. 

The  focus  on  U.S.  Coast  Guard  fracture  classifications  makes  the  database  very  useful  for 
the  documentation  and  tracking  of  fractures  and  the  reporting  to  the  USCG. 

•  Reporting  Module:  The  graphical  representation  of  fractures  over  the  ship  length  and 
the  ability  to  show  different  fracture  classes  separately  makes  the  reporting  capabilities  of 
FracTrac  very  well  suited  for  the  generation  of  CAIP  reports  and  the  internal  review  of 
fatigue  cracking  in  tankers. 

3.6  Structural  Inspection  Database  (SID) 

3.6.1  SID  -  Overview 

The  Structural  Inspection  Database  (SID)  is  a  software  program  created  to  collate  data  on 
structural  surveys,  defects  and  repairs  on  Canadian  Forces  vessels,  and  assist  in  the  assessment 
of  structural  integrity,  the  management  of  survey  and  repair  strategy,  and  the  pursuit  of  various 
related  Research  k.  Development  initiatives. 

SID  has  been  developed  by  MIL  Systems  Engineering  Inc,  Ottawa,  Ontario,  Canada'^ 
on  behalf  of  the  Canadian  Navy.  The  system  has  been  developed  with  the  purpose  to  automate  the 
inspection  data  recording  process  and  to  facilitate  the  generation  of  structural  integrity  reports. 

Although  SID  has  been  developed  for  the  use  with  Navy  vessels,  it  can  easily  be  adapted  to 
commercial  vessels.  SID  is  currently  used  by  the  Canadian  Navy  and  has  been  licensed  to  the 
Royal  Navy  in  the  U.K.  and  to  NWSC,  the  U.S.  Navy  ship  research  group. 

SID  is  intended  as  a  tool  with  which  the  entire  structural  inspection  information  base  of  the 
Canadian  Forces  maritime  arm  may  be  controlled  and  used  to  maximum  effectiveness.  SID  has 
the  capability  to  store  information  pertaining  to  every  ship  in  the  Forces. 

Each  ship  is  divided  into  its  internal  spaces  (or  compartments)  and  internal  or  external  features 
such  as  masts  (referred  to  as  elements).  In  turn,  every  defect  located  in  every  compartment  or 
element  of  every  ship  is  also  stored  within  SID. 

In  Canada,  the  program  is  used  by  surveyors  at  the  two  designated  survey  and  maintenance 
centers,  Halifax  on  the  Atlantic  side  and  Esquimalt  on  the  Pacific  side.  Data  analysis  and  evaluation 

^Complete  address  in  appendix  F 


22 


is  performed  at  the  Navy  headquarters  in  Ontario,  Canada.  The  headquarter  also  provides  the 
basic  setup  information  required  by  SID  for  surveyor  use  (i.e.  ship  information). 


3.6.2  SID  -  Program  Structure 

The  information  with  regard  to  the  program  structure  has  been  obtained  from  the  SID  User 
Manual,  [17],  that  has  been  supplied  together  with  a  demonstration  copy  of  the  program  to  the 
SSIIS  project. 

The  program  uses  the  Windows^^graphical  user  interface.  The  software  is  menu  based  and 
uses  a  pointer-type  approach,  in  which  the  current  ship,  deck,  compartment,  and  defect  remain  in 
effect  as  the  current  selections  until  a  different  configuration  is  selected. 

Structural  defects  are  specified  for  a  specified  ship,  compartment  and  deck.  The  currently 
selected  ship,  compartment  and  deck  are  shown  on  three  buttons  on  the  Main  Menu  Screen.  The 
buttons  may  be  used  to  select  the  current  ship,  compartment  or  deck. 

The  ship  and  compartment  button  bring  up  the  ship  or  compartment  browse  screens,  respec¬ 
tively.  The  deck  button  activates  the  deck  plan  screen,  from  which  the  current  deck  can  be  selected. 
These  screens  are  described  in  the  following  sections  in  more  detail. 

The  SID  menu  consists  of  the  following  eight  items: 

•  Administration:  The  administrative  items  in  this  menu  selection  are  intended  primarily 
for  the  system  administration  for  maintenance  tasks. 

•  Input:  Allows  the  input  of  ship,  compartment  and  defects  information.  Special  editing 
permission  is  required  to  enter  ship  and  compartment  information. 

•  Edit:  Allows  the  editing  of  ship,  compartment  and  defects  information.  In  addition,  it  is 
possible  to  edit  the  Statement  of  Structural  Integrity.  Special  editing  permission  is 
required  to  edit  ship  and  compartment  information. 

•  Browse:  The  browse  screens  allow  it  to  view  listings  of  available  ships,  compartments/ elements 
and  defects.  These  screens  are  used  to  select  the  current  ship,  compartment  or  defect.  Special 
editing  permission  is  required  to  delete  data  items  from  the  browse  screens. 

•  DeckPlan:  The  DeckPlan  menu  item  activates  the  graphical  deck  plan  display  of  SID.  The 
graphical  deck  plan  display  makes  it  possible  to  choose  decks,  compartments  and  defects 
without  using  the  actual  Main  Menu. 

•  Reports:  Three  types  of  reports  can  be  generated.  A  printout  of  the  DND  1754  form, 
a  listing  of  all  of  the  compartments  requiring  inspections,  and  a  custom  query  feature  to 
provide  user-specified  information. 

•  Exit:  Exit  SID. 

•  Help:  Opens  a  customized  help  system. 

Several  of  the  system  features  of  SID  require  special  editing  permissions  granted  through  the 
use  of  different  passwords  and  user  definitions.  This  guarantees  that  the  sensitive  system  data,  i.e. 
ship  and  compartment  information  cannot  be  changed  by  unauthorized  users. 

SID  uses  a  system  of  part  hierarchies  and  defect  types  to  clearly  identify  defects  in  structural 
components.  Using  a  part  hierarchy  makes  it  possible  to  store  the  exact  defect  location  without 
the  use  of  a  graphical  representation  of  the  structural  geometry. 

The  following  sections  describe  some  of  the  key  features  of  SID  in  more  detail.  This  includes 
among  others  the  ship  data  entry,  the  compartment  selection  and  the  defects  classifications. 
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3. 6. 2.1  SID  -  Ship  Data  Entry 

The  definition  of  a  ship  for  later  compartmentation  and  defect  input  is  the  necessary  first  step  in 
the  entire  SID  recording  process.  The  basic  vessel  related  information  is  entered  on  the  ship  data 
entry  screen.  This  screen  is  shown  in  Fig.  (3.6). 

This  entry  screen  is  used  to  enter  general  vessel  information  (name,  class,  home  port,  etc.), 
and  inspection  history  (including  inspection  dates  and  caveats  on  ship  operations).  Special  edit 
permission  is  required  to  enter  ship  information. 

As  part  of  the  vessel  information  it  is  necessary  to  enter  the  frame  location  on  the  ship. 
Surveyors  enter  defects  with  respect  to  frame  numbers,  and  it  is  therefore  necessary  to  provide 
information  that  links  the  frame  numbers  to  the  geometric  location  within  the  vessel. 

Deck  names  have  to  be  entered  for  all  decks.  Deck  names  are  limited  to  two  characters  and 
should  be  entered  from  top  to  bottom  in  order.  Decks  should  be  entered  as  they  appear  on  the 
ship’s  drawings. 

In  order  to  create  the  graphical  ship  deck  plan  it  is  necessary  to  enter  geometrical  information 
about  the  ship’s  compartments  and  elements.  A  compartment  is  a  normal  interior  space  on  the 
vessel  (i.e.,  enclosed  in  all  three  dimensions  by  decks  and/or  bulkheads.  An  element  is  an  item 
which  is  subject  to  structural  inspection  but  which  cannot  be  classed  as  a  compartment,  such  as 
masts  and  appendages. 

The  compartment  information  is  entered  on  the  comparimeni  data  entry  screen,  shown  in 
Fig.  (3.7).  The  compartments  are  defined  for  the  individual  decks.  Compartments  and  elements 
are  defined  using  what  is  known  as  a  bounding  box,  which  consists  of  a  rectangular  box  at  the 
extrem  extents  of  the  compartment  or  element,  or  portion  thereof.  In  general,  each  compartment 
or  element  is  defined  by  a  single  bounding  box  within  SID. 

Compartments  and  elements  are  specified  only  once  in  a  given  ship,  so  that  those  compartments 
which  extend  through  more  than  one  deck  in  the  vertical  direction  are  defined  as  part  of  the  lowest 
deck  upon  which  they  appear.  Compartments,  tanks,  and  voids  which  have  the  bottom  of  the  ship 
as  a  boundary  are  normally  placed  at  the  lowest  deck  level  of  the  model. 

If  a  ship  of  the  same  class  has  been  previously  entered,  all  of  the  geometric  information  of 
that  vessel  can  be  copied  to  a  new  vessel.  This  includes  the  frame  locations,  the  decks,  and  the 
compartment/element  definitions.  In  SID  this  process  is  referred  to  as  cloning. 

3. 6. 2. 2  SID  -  Defects  Entry 

The  defects  entry  is  the  core  of  the  Structural  Inspection  Database.  Fig.  (3.8)  shows  the  Defects 
Entry  screen.  The  defect  entry  screen  is  similar  in  layout  to  the  Canadian  Forces  form  DND-1756, 
the  Hull  Survey  Record  Sheet.  The  DND-1756  entries  for  ship  name  and  class,  deck,  compartment 
name,  and  frame  number  correspond  to  the  values  entered  in  the  defect  entry  screen.  Defect  type 
and  affected  part  and  the  detail  location  can  be  entered  in  SID  directly  based  on  information  in 
DND-1756. 

The  current  ship  name,  deck,  and  compartment  are  displayed.  A  sequential  defect  number 
is  assigned  and  displayed.  The  surveyor  name  and  a  check  to  indicate  if  the  entire  compartment 
was  surveyed  have  to  be  entered.  In  addition,  the  date,  when  the  defect  was  identified,  has  to  be 
specified. 

The  defect  location  is  defined  by  the  frame  number,  where  the  defect  is  located  and  the  height 
of  the  defect  above  the  deck  (entered  as  a  percentage  of  the  distance  between  the  deck  and  the 
deckhead).  The  transverse  location  of  the  defect  is  defined  either  by  the  longitudinal  number 
(including  P  or  S,  to  indicate  Port  or  Starboard  location)  or  as  a  distance  from  the  compartment 
centreline  (also  including  P  or  S).  Only  one  of  these  transverse  location  definitions  can  be  entered 
to  avoid  data  corruption. 

Other  information  about  the  defect  and  repair  are  entered  as  free  format  text  in  the  Additional 
Details,  Proposed  Repair  and  Action  Taken  boxes. 

The  defect  type  is  specified  in  a  pop-up  dialogue,  shown  in  Fig.  (3.9).  Several  standard  defect 
types  have  been  pre-defined,  along  with  the  possibility  to  enter  Other  non-standard  defects.  For 
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each  defect  type,  additional,  more  specific  information  is  required.  In  the  following,  the  different 
defect  types  are  listed: 

•  cracking 

—  mode:  brittle,  ductile,  fatigue  or  unknown 

—  length:  numeric 

•  corrosion 

—  general  or  pitting 

—  depth:  surface  (<  10%),  moderate  (<  25%),  deep  (<  50%),  or  excessive  (>  50%) 

—  localized  (<  %  of  total  area  of  structural  part),  scattered  (<  25%),  or  extensive  (>  25%) 

•  deformation 

—  tripped,  torn,  bent,  wrinkled,  dished,  or  oiher 

—  span 

—  depth 

—  description  recommended  for  type  other 

•  other 

—  description 

After  specifying  the  defect  type,  it  is  necessary  to  define  the  affected  part.  This  definition  is 
also  performed  using  a  pre-defined  hierarchy.  This  procedure  facilitates  the  grouping  and  sorting 
of  defects  for  analysis  by  standardizing  the  identification  procedure  for  defective  parts. 

The  hierarchy  is  organized  as  a  tree  structure,  where  each  branch  of  the  tree  becomes  more 
specific  about  the  defect.  The  tree  structure  has  been  implemented  through  the  use  of  list  boxes, 
each  corresponding  to  a  level  in  the  parts  hierarchy.  Fig.  (3.10)  shows  the  data  entry  screen  used 
to  identify  the  affected  part.  The  tree  structure  is  shown  for  a  sideshell  detail. 

3. 6. 2. 3  SID  -  Deck  Plan  View 

The  Deck  Plan  View  shows  the  graphical  representation  of  the  deck  plan.  Fig.  (3.11)  shows  part 
of  the  deck  plan  for  a  navy  fuel  supply  vessel.  The  deck  plan  shows  the  compartments  that  have 
been  entered  for  a  given  deck. 

The  deck  plan  can  be  used  to  choose  decks,  compartments,  and  defects,  moving  within  the 
SID  menu  structure  without  using  the  actual  main  menu.  Decks  are  selected  using  a  Deck  list  box. 
Once  a  deck  is  selected,  a  graphical  representation  of  the  spaces  on  that  deck  are  displayed.  The 
bounding  boxes  of  all  compartments  on  the  selected  deck  are  shown. 

3. 6. 2.4  SID  -  Reports 

The  Reports  menu  item  in  SID  is  used  to  generate  listings  of  data  from  the  information  stored  in 
the  database.  Three  types  of  reports  are  available: 

•  DND-1754  form:  A  printout  of  Part  3  of  the  process  involved  in  documenting  a  whole 
ship  survey  is  generated,  including 

—  The  HMC  Ships  Survey  Compartment  Listing  for  the  ship 
—  HMC  Ships  Survey  Compartment  Listing  Continuation  Sheets 

—  the  Hull  Survey  Record  Sheets  for  each  defect  on  the  ship 

—  the  Hull  Survey  Record  Continuation  Sheets 
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•  Compartments  requiring  survey:  A  list  is  generated  containing  all  compartments  or 
elements  that  have  not  been  inspected  since  a  user-specified  date 

•  Custom  query  results:  SID  uses  a  query  feature  that  makes  it  possible  to  extract  cus¬ 
tomized  information  from  the  database.  Selected  fields  can  be  chosen  from  the  database 
using  a  query  mechanism.  For  a  selected  set  of  fields,  the  scope  of  the  retrieval  and  the 
report  format  can  be  defined.  This  makes  it  possible  to  generate  customized  reports  for 
specific  purposes. 

3.6.3  SID  -  Summary 

SID  is  a  database  system  to  document  inspection  results  and  structural  failures,  originally  de¬ 
veloped  for  use  by  the  Canadian  Navy.  The  software  is  intended  to  collate  data  on  structural 
surveys,  defects  and  repairs  of  vessels,  and  to  assist  in  the  assessment  of  structural  integrity,  the 
management  of  survey  and  repair  strategy,  and  the  pursuit  of  various  R&D  initiatives. 

The  vessel  structure  is  defined  by  frames,  decks  and  compartments.  Compartments  are  entered 
for  each  deck.  The  bounding  box  for  each  compartment  is  used  to  create  a  graphical  display  of  the 
compartments  for  each  deck.  This  graphical  view  can  be  used  to  select  compartments  and  access 
defects  information. 

No  graphical  representation  of  the  structural  geometry  is  used  in  SID,  This  has  the  advantage 
that  the  required  initial  input  for  a  vessel  is  substantially  reduced.  It  is,  however,  not  possible  to 
show  the  defect  location  in  a  structural  component.  For  a  database  system,  that  is  designed  for 
a  large  number  of  different  ship  types,  the  decision  not  to  use  a  graphical  representation  of  the 
structural  geometry,  greatly  reduces  the  setup  costs  and  the  necessary  data  storage  capacities. 

Defects  are  defined  by  the  defect  location  (frame  #,  transverse  position  with  respect  to  the 
current  deck,  transverse  position),  the  affected  part,  and  the  type  of  defect.  A  tree  structure 
approach  is  used  to  identify  the  affected  part.  This  method  makes  it  possible  to  precisely  identify 
a  defect  location  and  to  perform  database  searches  for  a  particular  location  or  detail  component. 
Especially  important  for  fatigue  cracks  is  the  ability  to  identify  the  local  component  in  which  the 
crack  originated.  Due  to  the  importance  of  the  tree  structure  for  the  identification  of  the  exact 
defect  location  and  the  detail  configuration,  the  complete  tree  structure  is  shown  in  Appendix  B. 

SID  contains  report  generating  options  that  are  tailored  to  the  need  of  the  Canadian  Navy. 
The  inclusion  of  these  report  generation  options  greatly  enhances  the  usefulness  of  the  database 
system  and  can  serve  as  a  guideline  for  the  design  of  the  CAIP  report  implementation  in  SSIIS. 

Overall,  the  Structural  Inspection  Database  (SID),  developed  by  MIL  Systems,  Ontario,  CANADA, 
is  a  very  powerful  database  system  for  the  recording  and  analysis  of  structural  failures  in  ships. 
The  system  contains  most  of  the  necessary  information  to  generate  CAIP  reports.  The  use  of 
a  tree  structure  to  identify  the  geometric  configuration  of  the  defect  location  provides  a  suitable 
alternative  to  the  graphical  representation  of  defect  locations  and  can  also  be  used  for  detailed 
database  analyses. 


3.7  Definition  of  Corrosion  Limits  (DCL) 

3.7.1  Overview 

A  research  project  has  been  conducted  at  the  Department  of  Naval  Architecture  k  Offshore  En¬ 
gineering  at  the  University  of  California  at  Berkeley^  titled  Development  of  a  Rational  Basis  for 
Defining  Corrosion  Limits  in  Tankers.  This  project  has  been  a  continuation  of  the  Structural 
Maintenance  Project  for  New  k  Existing  Ships  (SMP)  conducted  at  Berkeley  in  1990  -  1992. 

It  was  the  objective  of  the  DCL  project  to  make  advances  in  the  area  of  setting  allowable  limits 
for  the  wastage  of  tanker  structures  based  on  a  procedure  involving  rational  analytical  techniques 
as  an  adjunct  to  the  traditional,  experience  based  approaches. 

^Complete  address  in  appendix  F 
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Current  practice  in  the  definition  of  corrosion  is  based  on  a  unified  hull  girder  longitudinal 
strength  standard  as  defined  by  the  International  Association  of  Classification  Societies  (lACS). 
The  standard  is  based  on  the  aquired  experience  with  successful  designs  and  is  well  established 
for  traditional  design  and  construction  concepts.  A  safety  margin  is  included  in  the  formulae  for 
longitudinal  strength  to  account  for  the  corrosion  wastage. 

In  the  DCL  project,  the  definition  of  corrosion  limits  is  viewed  as  only  one  component  of  an 
overall  Life  Assessment  procedure.  Corrosion  wastage  is  only  one  of  the  possible  failure  modes  for 
a  vessel.  In  order  to  develop  a  system  that  can  be  used  for  all  of  the  possible  failure  modes,  a 
database  system  is  used  to  contain  all  the  necessary  input  information.  This  includes  the  general 
vessel  and  structural  geometry  description,  vessel  survey  information  and  historic  performance 
data. 

As  an  application  example,  the  life  assessment  procedure  is  implemented  for  the  failure  modes 
of  buckling  instability  of  the  ships  structural  components.  A  database  system  is  used  to  store  and 
manage  all  necessary  input  data  and  intermediate  results. 

3.7.2  Program  Structure 

The  general  approach  and  the  program  structure  are  documented  in  detail  in  [24].  The  DCL 
project  uses  a  life  assessment  procedure  developed  by  Nippon  Kaiji-Kyokai  for  ships  and  offshore 
structures.  This  procedure  describes  the  reliability  of  a  vessel  in  terms  of  the  availability  of  the 
vessel,  where  availability  is  defined  as  the  percentage  of  time  that  the  vessel  must  be  in  service. 

A  vessel  is  in  general  out  of  service  due  to  inspections  or  repairs.  These  outages  can  be 
attributed  to  three  major  categories  of  events: 

1.  Planned  Inspection  and  Maintenance  Routines  (IMR) 

2.  Repair  of  structural  failures  that  are  due  to  a  weakness  in  the  ship’s  structure. 

3.  Repair  of  structural  failures  following  accidents  that  are  caused  by  unforeseen  extreme  load¬ 
ing  conditions  and/or  human  and  organizational  error  (HOE). 

A  numerical  quantity  called  unavailability  can  be  defined  as  that  fraction  of  time  that  the  vessel 
is  out  of  service  (years-per-year)  due  to  each  of  the  above  three  categories.  Respectively,  these 
components  of  the  total  unavailability,  U,  can  be  designated  as  Upl,  Usf,  Uqt-  the  availability, 
Av,  is  expressed  as: 

Av  =  l  —  U  =  1  —  {UpL  +  Usf  +  Uqt) 

In  order  to  support  the  types  of  analyses  involved  in  the  assessment  of  the  availability  it  is 
necessary  to  create  a  database  system.  This  database  system  has  to  contain  the  following  three 
major  components: 

•  A  preliminary  survey  database  that  would  contain,  among  other  things,  information  concern¬ 
ing  the  vessels  particulars,  its  cargo,  its  route,  its  corrosion  protection  system,  its  inspection 
and  maintenance  routine,  its  intended  service  life,  and  its  prescribed  availability. 

•  A  database  of  records  and  statistics  of  unforeseen  accidents,  instances  of  human  error  re¬ 
sulting  in  accidents. 

•  A  database  containing  referential  data  such  as  gauging  reports,  crack  inspections,  the  loca¬ 
tion  and  nature  of  structural  failures,  the  time  it  took  to  repair  them,  etc... 

A  database  management  system  is  necessary  to  maintain  the  data  and  control  the  flow  of 
information.  Fig.  (3.15)  shows  a  data  flow  diagram  (DFD)  depicting  the  role  of  the  database 
management  system  within  the  context  of  the  DCL  project. 

In  order  to  calculate  the  unavailability  due  to  structural  failures,  Usf,  A  is  necessary  to  classify 
structural  failures  based  on  their  general  failure  moded.  Failures  related  to  the  longitudinal  strength 
of  the  hull  girder  can  be  grouped  into  five  categories: 
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•  Yield  failure  due  to  bending  of  the  ship 

•  Compression  instability  buckling 

•  Brittle  fracture 

•  Fatigue  fracture 

•  Ultimate  plastic  collapse 

In  the  DCL  project,  only  the  two  failure  modes  compression  instability  buckling  and  ultim.ate 
plastic  collapse  are  treated.  For  each  failure  mode,  the  Mean  Time  Between  Failures  (MTBF)  and 
the  Mean  Time  to  Repair  (MTTR)  have  to  be  calculated. 

3. 7. 2.1  Evaluation  of  Structural  Failures,  Usf 

The  unavailability  due  to  year-to-year  type  structural  failures,  Usf,  is  defined  as  a  function  of  the 
mean  time  between  failure  incidents  and  the  mean  time  that  the  vessel  is  unavailable  while  the 
failure  is  being  repaired.  Usf  is  &  function  of  time  and  has  to  be  calculated  for  all  failure  modes. 

The  general  procedure  for  the  calculation  of  Usf  for  a  specific  vessel  involves  the  evaluation 
of  the  loading  effects  based  on  the  specific  vessel  geometry  and  loading  environment.  After  calcu¬ 
lating  the  capacity  of  the  vessel  structure,  a  reliability  based  analysis  is  performed  to  estimate  the 
probability  of  failure  for  the  particular  failure  mode  based  on  the  calculated  loading  and  capacity. 
This  then  leads  to  the  calculation  of  C/sf  for  a  given  time  step. 

Using  corrosion  data  obtained  from  the  referential  database,  the  corrosion  wastage  for  each 
element  in  the  section  is  calculated  and  Usf  is  calculated  for  the  next  time  step.  This  process  is 
repeated  until  Usf  is  defined  over  the  entire  design  life  of  the  vessel. 

The  necessary  vessel  information  is  obtained  from  the  preliminary  database,  described  in  section 
3. 7. 2. 2.  In  addition,  the  necessary  vessel  sections  are  defined  using  the  notation  of  elements. 

The  demand,  or  loading,  is  based  on  a  probabilistic  model  of  the  extreme  vertical  bending 
moment  for  a  specific  vessel.  This  model  uses  a  spectral  representation  of  the  wave  environment 
on  a  vessel  route  specified  by  the  time  spent  in  different  Marsden  zones.  The  extreme  total  vertical 
bending  moment  is  comprised  of  the  still  water  bending  moment  and  the  wave  bending  moment. 
Both  are  considered  to  be  random  variables. 

The  capacity  of  a  vessel’s  structure  to  resist  the  different  failure  modes  is  represented  by 
probability  distributions.  The  capacity  can  generally  be  described  in  terms  of  load/displacement 
curves  for  both  local  and  ultimate  failure  modes. 

3. 7. 2. 2  DCL  -  Database  System 

The  three  different  database  modules  that  are  controlled  by  the  database  management  system 
are  used  for  the  general  life  assessment  analyses.  This  relationship  is  shown  in  Fig.  (3.16).  The 
referential  database  contains  fleet-wide  general  data,  vessel  routes  and  inspection  data.  The  pre¬ 
liminary  database  contains  vessel  specific  data,  vessel  structural  information  and  mission  profiles. 
The  accident  record  database  contains  data  related  to  human  &  organizational  errors  (HOE)  and 
other  accident  data. 

The  referential  database  that  is  used  for  this  project,  contains  mainly  inspection  results  (gaug¬ 
ing  reports)  that  are  necessary  to  determine  the  corrosion  rates  for  particular  locations  in  a  vessel. 
In  addition,  it  is  intended  to  contain  data  related  to  the  location  and  nature  of  structural  failures, 
including  the  time  it  took  to  repair  particular  failures. 

The  preliminary  database  is  intended  to  provide  all  of  the  vessel  specific  information  that  is 
needed  as  input  for  the  different  analysis  modules.  A  hierarchic  definition  of  the  vessel’s  internal 
arrangement  is  used.  This  definition  is  shown  in  Fig.  (3.17).  It  shows  the  hierarchy  as  a  one-to- 
many  relationship.  For  every  vessel  there  are  many  section  separated  by  transverse  bulkheads, 
and  for  every  section  there  are  a  number  of  deck  levels  separated  by  decks  and  inner  bottoms, 
and,  finally,  for  every  deck  level  there  are  a  number  of  transverse  compartments  separated  by 
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longitudinal  bulkheads.  Although  simple,  this  model  is  considered  to  allow  a  realistic  description 
of  the  internal  arrangement  of  a  vessel. 

For  load  calculations,  such  as  the  vertical  wave  bending  moment,  the  hnll  geometry  has  to 
be  available.  For  this  purpose,  the  vessel  is  subdivided  longitudinally  into  a  number  of  stations. 
For  each  station  the  weight  and  the  hull  form  is  needed.  Fig.  (3.18)  shows  the  station  description 
for  the  purpose  of  load  calculations.  For  each  station  the  half  breadth,  the  height,  and  the  girth 
distance  are  entered  for  a  sufficient  number  of  points.  This  information  in  conjunction  with  ciirve 
fitting  procedures  is  sufficient  to  describe  the  hull  geometry. 

In  addition  to  the  hull  description  contained  in  the  preliminary  database,  information  with 
respect  to  the  mission  profile  of  each  vessel  is  included.  This  information  is  necessary  to  calculate 
the  long-term  loading  based  on  the  wave  environment  encountered  by  the  vessel. 

3.7.3  DCL  -  Summary 

The  DCL  project  uses  a  database  to  contain  and  handle  all  of  the  information  requirements  for 
the  probabilistic  analysis  of  the  unavailability  of  a  vessel.  The  project  demonstrates  the  need  for 
and  the  advantage  of  a  general  database  system  for  vessel  information.  The  integration  of  the 
information  in  a  relational  database  makes  it  possible  to  develop  the  analysis  procedures  in  a 
modular  fashion. 

The  developed  database  structure  is  not  detailed  enough  to  serve  as  a  prototype  for  the  SSIIS 
database  structure.  However,  it  can  be  used  as  a  good  example  for  the  benefits  of  a  vessel  infor¬ 
mation  database. 


3.8  The  Ship  Information  Management  System  (SIMS) 

3.8.1  Overview 

The  Ship  Information  Management  System  has  been  developed  as  part  of  the  Structural  Main¬ 
tenance  Project  for  New  k  Existing  Ships  (SMP)  at  the  Department  of  Naval  Architecture  k 
Offshore  Engineering  at  the  University  of  California  at  Berkeley®  . 

The  objective  of  the  development  was  to  create  a  database  system  that  combined  all  relevant 
information  regarding  the  operation  of  oil  tankers  including  the  results  of  all  surveys  that  are 
performed  during  the  lifetime  of  a  vessel.  The  project  participants  (tanker  operators,  classification 
societies,  shipyards)  would  thus  obtain  a  common  database  system  that  allows  data  storage  and 
management.  Within  the  SMP  project  the  database  served  the  following  purposes: 

•  Definition  and  calculation  of  average  corrosion  rates  based  on  gauging  information  contained 
in  the  database. 

•  Definition  of  data  structures  suitable  to  document  crack  incidents  detected  in  vessel  surveys. 

•  Development  of  a  sufficiently  large  data  sample  to  calculate  target  failure  probabilities  based 
on  actual  failure  data.  This  information  was  necessary  for  the  verification  and  calibration  of 
the  developed  fatigue  life  evaluation  software. 

During  the  first  year  of  the  SMP  project  two  separate  database  systems  have  been  developed, 
one  for  corrosion  data  and  one  for  crack  data.  A  corrosion  database  has  been  developed  to  contain 
the  results  of  gauging  reports.  A  large  amount  of  survey  data  has  been  included  in  this  database. 
Software  has  been  developed  to  calcnlate  the  average  corrosion  rates  for  different  ship  details, 
locations  and  cargo.  This  development  has  been  extensively  documented  in  [29]  and  [3]  and  [2]. 

Parallel  a  database  system  has  been  developed  to  contain  of  crack  surveys.  This  development  of 
the  database  format  has  been  closely  related  to  the  development  of  the  CATSIR  database  system. 

®  Complete  address  in  appendix  F 
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Survey  results  for  several  ships  has  been  included  in  the  crack  database.  These  survey  results 
have  been  used  to  perform  a  set  of  preliminary  data  analyses.  The  development  of  the  crack 
database  and  the  results  of  the  analyses  have  been  documented  in  [32]. 

The  experience  that  has  been  gained  through  the  development  of  the  two  database  systems 
and  the  need  to  develop  a  combined,  integrated  database  system  that  contains  both  the  corrosion 
and  the  crack  information  have  let  to  the  development  of  an  improved  database  format.  The 
comparison  with  several  existing  crack  databases  that  have  been  supplied  by  participants  of  the 
SMP  project  has  also  been  a  great  help  for  the  definition  of  the  database  structure. 

3.8.2  Summary  of  the  Corrosion  Database  Development 

One  main  objective  of  the  Structural  Maintenance  Project  for  New  and  Existing  Ships  (SMP)  was 
to  study  the  effects  of  corrosion  on  internal  tanks  on  ocean  going  oil  tankers  and  product  carriers. 
This  includes  the  study  of  the  primary  corrosion  effects,  the  evaluation  of  the  different  corrosion 
protection  systems  and  the  development  of  a  database  system  with  the  main  goal  to  determine 
corrosion  rates  for  various  types  of  tanks  and  conditions  within  tanks. 

The  results  of  the  corrosion  part  of  the  SMP  project  are  documented  in  [29].  This  report 
contains  the  following  topics: 

•  Summary  of  Literature  Review 

•  Basic  Corrosion  Mechanisms  in  Ships 

•  Corrosion  Protection  Systems 

•  Summary  of  Data  Analysis  Method 

•  Summary  of  Corrosion  Rates  obtained  from  Analysis 

•  Conclusions  and  Recommendations 

In  the  appendix  of  [29]  a  method  is  outlined  that  uses  a  reliability  format  to  determine  average 
corrosion  rates  and  to  define  wastage  limits. 

In  addition  Corrosion  questionnaires  that  have  been  sent  to  project  participants  are  docu¬ 
mented.  Sample  data  sheets  from  corrosion  surveys  that  have  been  used  for  the  data  input  are 
also  documented. 

In  the  following  section  the  material  in  the  corrosion  report  that  is  related  to  the  development 
of  the  corrosion  database  format  is  summarized.  This  will  help  to  document  the  changes  that  have 
been  made  in  the  database  format  to  both  improve  the  database  and  to  develop  an  integrated 
database  format  containing  crack  and  corrosion  data. 

3. 8. 2.1  Development  of  Corrosion  Database  Format 

The  corrosion  database  format  has  been  designed  to  include  the  data  that  is  found  in  a  gauging 
report.  This  data  is  usually  obtained  using  an  ultrasonic  thickness  (UT)  device.  It  is  the  intent 
of  gauging  surveys  to  determine  the  average  corrosion  rate  in  a  plate.  For  this  purpose  several 
measurements  are  taken  that  are  assumed  to  be  representative  of  the  corrosion  in  the  plate.  Using 
statistical  analysis  procedures  the  mean  or  average  corrosion  can  be  determined. 

In  general,  the  corrosion  rate  is  influenced  by  the  environment  the  element  is  exposed  to.  This 
includes  the  type  of  tank  (ballast  or  cargo),  the  chemical  composition  of  the  tank  contents,  the 
type  of  structural  member,  etc.  . 

The  database  has  to  be  capable  to  include  all  these  influencing  factors  in  order  to  be  a  valuable 
source  of  information.  Based  on  a  questionnaire  that  has  been  sent  out  to  the  project  participants, 
a  list  of  important  influence  factors  for  which  reasonable  amounts  of  quality  data  exist,  has  been 
compiled.  This  list  is  summarized  in  the  following  table. 
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Ship  Size 

Tank  Type 

Cargo  Sulfur  (%) 

Delivery  Date 

Time  in  Cargo 

Cargo  Water  (%) 

Cargo  Type 

Time  in  Ballast 

Wax  in  Cargo 

Double  Bottom 

Corrosion  Protection  System 

Heated  Cargo 

Double  Side 

Ballast  Type 

Tank  Washing 

Class  Society 

Tank  Temperature 

Corrosion  Type 

Trade  Route 

Tank  Humidity 

Corroded  Detail 

Tank  Location 

Inert  Gas 

Location 

The  factors  were  separated  into  three  main  types:  Ship  specific  data,  Tank  specific  data,  and 
Incident  specific  data.  Ship  specific  data  are  those  data  which  are  assumed  to  apply  to  all  gaugings 
in  all  tanks  for  all  surveys  of  a  single  ship.  They  include:  ship  size,  date  of  build,  cargo  type  (crude 
or  product),  double  side,  double  bottom,  class  society,  trade  route. 

The  tank  specific  data  include:  tank  type,  time  in  ballast  (for  ballast  tanks),  corrosion  pro¬ 
tection  system,  fresh  or  salt  water  ballast,  clean  or  dirty  ballast,  sulfur,  water,  and  wax  content 
of  cargo,  presence  of  heated  cargo,  IGS  gas  quality,  method  of  tank  washing.  Just  as  in  the  ship 
specific  data,  this  will  be  assumed  to  remain  constant  over  the  life  of  the  ship. 

The  incident  data  was  taken  for  every  incident  of  corrosion  included  in  the  database.  An 
incident  of  corrosion  is  defined  as  a  location  where  a  gauging  was  taken.  Thus  every  gauging 
represents  a  corrosion  incident,  and  every  gauging  from  the  survey  is  included  in  the  database.  The 
incident  data  includes:  ship  age  at  survey,  the  type  of  corrosion,  the  type  of  detail  the  corrosion  is 
gauged  at,  and  some  relative  location  in  the  tank  of  the  gauging. 

3. 8. 2. 2  Representation  of  Detail  Types 

The  types  of  details  that  were  included  in  the  corrosion  database  are  represented  by  code  words. 
These  code  words,  based  on  the  set  of  details  used  by  the  Tanker  Structure  Cooperative  Forum 
(TSCF),  are  compatible  with  the  code  words  used  in  the  crack  database.  The  details  for  the 
corrosion  database  do  not  have  the  same  level  of  sophistication,  e.g.  brackets  of  any  type  are  not 
included  in  the  corrosion  database.  It  was  felt  that  the  large  increase  in  the  degrees  of  freedom 
(and  so  a  diminished  sample  size  for  each  of  the  details)  implied  by  the  larger  list  would  yield  a 
unnecessarily  diminished  confidence  in  the  results.  It  is  important  in  a  statistical  study,  because 
of  the  variable  nature  of  corrosion,  to  obtain  a  sufficiently  large  sample  size,  so  that  any  statistical 
characterization  developed  at  least  approaches  reality.  The  TSCF  list  of  basic  details  was  chosen 
as  a  basis  which  would  satisfy  both  the  requirements  of  brief  generality,  as  well  as  compatibility 
with  the  fatigue  database. 

3. 8. 2. 3  Incident  Location 

The  location  of  the  gauging  is  given  simply  in  the  longitudinal,  and  vertical  frames  as  either  forward- 
middle-aft  third  of  the  tank  or  upper-middle-lower  third  of  the  tank  respectively.  A  similar  format 
is  used  in  the  crack  database.  Any  more  detailed,  or  rather  specific,  manner  of  identifying  location 
would  have  meant  the  same  increase  in  degrees  of  freedom  as  discussed  above. 

3.8.3  Summary  of  the  Crack  Database  Development 
3.8. 3.1  Field  Trips 

Several  Members  of  the  project  team  have  visited  tankers  during  special  surveys  or  other  opportu¬ 
nities.  These  visits  were  intended  to  provide  insights  into  survey  methods  and  procedures  and  to 
observe  inspection  evaluations,  repair  design  and  repair  fabrication  associated  with  cracking  and 
corrosion  in  structural  components  of  tankers.  The  impressions  developed  from  these  field  trips 
have  been  documented  in  the  fatigue  database  report  [32]. 
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3. 8. 3. 2  Location  Representation 

The  definition  of  the  location  of  a  crack  in  a  ship  and  the  representation  of  this  location  proved 
to  be  a  very  complex  problem.  This  problem  arises  due  to  the  fact  that  it  was  not  possible  to  link 
the  crack  data  to  graphic  representations  of  the  ship  geometry. 

Economic  considerations  requiring  a  minimum  of  data  input  had  to  be  balanced  with  the  need 
for  an  accurate  representation  of  the  location  and  the  crack  geometry.  Since  it  is  important 
to  understand  the  original  representation  that  has  been  developed  in  order  to  appreciate  the 
modifications  made  in  the  development  of  the  Ship  Maintenance  Information  System  (SMIS), 
this  original  representation  of  the  location,  as  documented  in  [32],  is  repeated  in  the  following: 

3.8.4  Combined  Database  Structure  for  SIMS 

Two  database  formats  have  been  developed  as  part  of  the  Structural  Maintenance  Project.  One  to 
document  and  archive  the  results  of  gauging  surveys  i.e.  corrosion,  the  other  one  to  document  and 
archive  the  results  of  structural  surveys,  i.e.  cracks  and  other  structural  damage.  These  database 
formats  had  to  be  combined  in  order  to  create  a  versatile  database  management  system.  In  order 
to  reduce  the  amount  of  redundant  information  and  to  provide  a  means  to  prohibit  illegal  input 
a  relational  database  format  has  been  used.  A  short  description  of  relational  database  theory  is 
given  in  section  3.2. 

Based  on  the  experience  from  using  the  database  formats  that  have  been  developed  earlier  for 
the  crack  and  corrosion  databases,  several  improvements  have  been  made  to  these  formats.  These 
improvements  and  reasons  for  it  are  outlined  in  the  following. 

The  combined  database  has  to  be  able  to  contain  all  the  ship  relevant  information.  In  addition 
all  survey  results  have  to  be  stored  and  have  to  be  easily  accessible.  The  database  has  to  be 
detailed  enough  to  allow  scientific  analysis  of  the  data. 

The  crack  and  corrosion  databases  both  require  that  ship  specific  information  is  available, 
such  as  tank  numbers,  longitudinal  numbers,  etc.  .  In  addition  it  is  desirable  to  use  the  same 
method  of  identifying  the  detail  by  using  a  set  of  code  words  defining  principal  location  and  detail 
components. 

Most  data  items  that  are  included  in  the  database  consist  of  some  form  of  code  word.  For  each 
item  there  is  in  general  only  a  limited  number  of  possible  code  words. 

In  the  originally  developed  database  formats  most  code  words  were  defined  only  in  the  respec¬ 
tive  reports.  One  example  of  this  procedure  is  the  definition  of  the  side.  The  crack  database  format 
defines  the  side  by  three  code  words  (P,  C,  S)  for  port,  center  and  starboard,  respectively.  The 
three  code  words  are  only  defined  in  the  database  report. 

The  database  management  system  then  has  to  be  developed  specifically  according  to  the  written 
definitions.  This  is  a  severe  limitation  since  the  change  of  a  code  word  requires  the  change  of  the 
database  management  software. 

The  limitations  of  this  procedure  have  been  experienced  during  the  data  input  and  the  data 
analysis.  The  modified  database  format  therefore  uses  a  different  procedure.  For  all  information 
that  is  input  using  code  words,  these  code  words  have  to  be  defined  in  the  database.  This  is  done 
by  using  a  data  relation  that  contains  all  available  code  words  for  one  data  item  together  with 
a  description  of  the  code  word.  This  allows  it  to  easily  add  code  words  and  also  to  change  the 
description  of  one  code  word. 

The  database  management  system  then  simply  links  the  input  of  one  data  item  to  the  data 
relation  containing  the  list  of  available  code  words.  This  procedure  makes  it  impossible  to  enter 
invalid  information.  The  database  management  system  also  does  not  have  to  be  changed,  if  the 
list  of  code  words  is  changed. 

The  above  example  of  the  side  would  be  implemented  by  providing  an  additional  relation  for 
the  side  code  words.  This  relation  has  three  entries.  Each  entry  contains  the  code  word  and  a 
description,  e.g.  the  code  word  P  and  the  description  port.  The  actual  implementation  is  slightly 
different.  Here  the  side  is  defined  by  five  different  code  words.  The  exact  format  is  described  in 
section  7.3.9. 
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The  database  structure  has  been  developed  to  include  all  ship  specific  information  and  the 
corrosion  and  crack  related  survey  results.  The  overall  database  format  is  shown  in  Fig.  (3.12). 
The  figure  shows  the  overall  data  structure.  Only  the  name  of  each  relation  is  displayed. 

The  data  structure  is  primarily  subdivided  in  two  parts,  the  vessel  description  and  the  survey 
results.  The  vessel  description  is  contained  in  the  class,  the  vessel  and  the  tank  relations.  Each 
of  these  relations  has  several  other  relations  associated  with  it  that  contain  secondary  information 
and  assure  data  integrity. 

The  corrosion  and  crack  relations  use  the  same  definitions  to  describe  the  detail  configuration. 
Each  of  the  two  relations  also  has  associated  secondary  relations  that  assure  data  integrity  and 
supply  necessary  data  definitions. 

3.8.5  Data  Analysis 

As  part  of  the  database  development  process,  extensive  data  analysis  has  been  performed  using 
data  from  original  survey  reports  and  data  obtained  from  other  crack  databases.  The  data  analysis 
was  performed  for  two  main  reasons: 

•  To  show  possible  applications  for  the  developed  database 

•  To  determine  the  areas  and  types  of  structural  details  that  are  most  likely  to  be  subject  to 
fatigue  damage 

Fig.  (3.13)  shows  the  distribution  of  sideshell  cracks  over  the  shiplength,  which  is  repre.sented 
by  the  frame  numbers.  Most  sideshell  cracks  are  concentrated  in  two  areas  of  the  ship,  frames  29 
-  35  and  frames  53  -  57. 

For  each  tank  the  distribution  of  the  sideshell  longitudinal  cracks  over  the  ship  height  has 
been  plotted.  The  ship  height  is  represented  by  the  longitudinal  #.  Fig.  (3.14)  shows  the  crack 
distribution  over  the  ship  height  for  one  tank  4.  A  total  of  212  cracks  were  found  in  this  tank. 
About  90%  of  these  cracks  occurred  in  longitudinals  30  -  36.  These  two  figures  give  a  good  example 
for  the  possible  use  and  the  benefits  of  a  vessel  database  that  contains  the  results  of  structural 
surveys. 

3.8.6  SIMS  -  Summary 

The  original  database  formats  that  have  been  developed  to  contain  the  survey  results  for  crack 
and  corrosion  inspections  have  been  combined  and  improved  to  create  the  Ship  Maintenance  In¬ 
formation  System  (SMIS).  This  development  has  been  based  on  experiences  gained  through  the 
data  analyses  that  have  been  performed  and  on  comparisons  with  existing  ship  databases. 

The  developed  system  uses  the  concept  of  relational  database  theory.  This  has  several  impor¬ 
tant  benefits,  such  as  data  integrity  and  a  minimization  of  data  redundancy. 

The  database  structure  does  not  rely  on  a  graphical  representation  of  the  vessel  geometry  to 
represent  crack  and  corrosion  locations.  It  is  therefore  not  necessary  to  include  hull  offsets  and 
structural  drawings  in  the  database.  This  makes  the  system  more  usable  for  a  wide  variety  of 
possible  users.  It  requires  less  time  to  include  additional  ship  classes  and  is  therefore  much  less 
man-power  intensive  than  most  other  system.  The  structure  is  set  up  in  a  way  that  allows  it  to 
non-dimensionalize  locations  in  a  ship,  which  makes  it  possible  to  compare  data  for  different  classes 
of  ships  in  a  realistic  manner. 


3.9  Database  Usage  for  Research  Purposes 

The  increased  occurence  of  fatigue  cracks  in  oil  tankers  has  resulted  in  several  research  efforts  to 
develop  or  improve  fatigue  life  analysis  procedures.  Due  to  the  complexity  of  both  the  long-term 
loading  and  the  representation  of  fatigue  strength  of  ship  structural  details  the  calculated  fatigue 
life  can  vary  considerably. 
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It  is  therefore  desirable  to  use  actual  damage  statistics  to  calibrate  the  analysis  procedures. 
This  can  be  accomplished  through  the  use  of  database  systems.  One  of  the  reasons  to  develop  a 
database  system  as  part  of  the  SMP  project  was  the  need  to  obtain  damage  statistics  for  cracks  in 
oil  tankers.  Survey  results  for  several  tankers  have  been  included  in  the  database.  In  addition  data 
from  existing  databases  maintained  by  tanker  operators  has  been  included  in  the  SMP  database. 
This  process  is  described  in  detail  in  [32]. 

The  data  contained  in  the  first  version  of  the  SMP  database  has  been  used  by  other  researchers 
for  verification  purposes.  In  [39]  a  realistic  wave  model  has  been  developed  to  calculate  the  fatigue 
damage  in  the  side  shell  longitudinals  of  ships.  The  model  has  been  used  to  analyse  a  segregated 
ballast  tanker,  and  the  results  are  compared  to  previously  registered  fatigue  cracks  that  are  included 
in  the  SMP  database. 

In  a  research  project  sponsored  by  the  SNAME  Technical  and  Research  Committee  crack  data 
for  a  class  of  vessels  contained  in  the  SMP  database  has  been  used  to  validate  analysis  results.  The 
project  is  described  in  [19]. 


3.10  Conclusions 

Several  existing  database  systems  for  the  storage  and  analysis  of  structural  survey  results  of  ships 
have  been  evaluated  to  determine  abilities  of  each  system  to  generate  CAIP  reports  and  to  gain 
experience  for  the  development  of  a  general  Ship  Structural  Integrity  Information  System  (SSIIS). 

None  of  the  database  systems  contains  sufficient  information  to  generate  CAIP  reports  that 
are  fully  compatible  with  the  developed  CAIP  reporting  format,  see  chapter  5.7. 

Different  strategies  have  been  used  to  represent  failure  locations  and  to  describe  the  structural 
configurations.  The  use  of  AutoCad”^^  drawings  results  in  a  large  amount  af  data  that  needs 
to  be  stored,  but  has  the  advantage  that  graphical  representations  of  failure  locations  are  readily 
available.  None  of  the  systems  that  use  AutoCad^^  have  solved  the  problem  of  linking  the  failure 
locations  on  a  drawing  directly  to  a  failure  incident  in  the  database  in  a  fashions  that  prevents 
possible  data  corruption. 

The  data  analysis  capabilities  of  the  different  database  systems  have  to  be  improved  to  generate 
meaningful  CAIP  reports  that  clearly  document  trends  and  show  critical  failure  areas. 

Overall,  the  evaluation  of  existing  databases  hcis  been  very  important  for  the  development  of 
the  SSIIS  database  structure.  Additional  user  experience  with  the  different  database  systems  has 
to  be  gathered  to  aid  in  the  final  definition  of  a  future  SSIIS. 
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Select  the  nearest  point  on  Ship  Panel: 
Locate  Point: 

Command: 


Figure  3.1:  FracTrac  -  AutoCad^^  Screen  View 
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Figure  3.2:  FracTrac  -  AutoCad^^  Fracture  View 
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Report;  F94A  S.S.  Syper  Tanker  Tag: 


Figure  3.3:  FracTrac  -  Fracture  Input  Screen 


Figure  3.4;  FracTrac  -  Cargo  Block  Fracture  History  Screen 
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Figure  3.5:  FracTrac  -  Fracture  Distribution  Screen 
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Figure  3.6:  SID  -  Ship  Data  Entry  Screen 
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Figure  3.7:  SID  -  Compartment/Element  Data  Entry  Screen 


Figure  3.8:  SID  -  Defects  Entry  Screen 
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Figure  3.10:  SID  -  Affected  Part  Entry  Screen 
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Figure  3.11:  SID  -  Deck  Plan  View  Screen 
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No.  of  Cracks 


Figure  3.12:  SMP  Tanker  Database:  Overall  Structure 

#  of  Cracks  over  Shiplength 

(Side  Shell  Cracks  only) 


Frame  # 

Figure  3.13:  Number  of  Sideshell  Cracks  over  Shiplength 
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Total  Number  of  Cracks  in  Tank  4:  234 


Figure  3.14;  Side  Shell  Longitudinal  Cracks  in  Tank  4 
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Figure  3.16:  Database  Use  for  Life  Assessment  Analyses 


Figure  3.17:  DCL  -  Vessel  Internal  Arrangement  Hierarchy 
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Figure  3.18:  DCL  -  Hull  Geometry  Description 
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Chapter  4 

Information  Requirements  for 
Analysis  Applications 


During  design,  construction,  maintenance  and  operations  of  an  oil  tanker  a  large  number  of  software 
programs  are  used  to  perform  structural  analysis,  cargo  scheduling,  loading  procedures,  vessel 
routing,  etc.  In  general,  these  programs  have  individual,  proprietary  input  file  formats.  In  many 
cases,  the  preparation  of  the  input  files  requires  a  substantial  amount  of  time.  This  is  especially 
true  for  programs  that  require  the  input  of  the  ship’s  hull  and  compartments. 

With  the  advent  of  powerful,  relational  database  systems  and  the  increase  in  storage  capacities 
of  desktop  computers,  it  has  become  possible  to  develop  ship  database  systems  that  contain  most 
of  the  information  needed  to  use  these  analysis,  scheduling,  loading  or  vessel  routing  programs. 

A  general  ship  database  can  therefore  be  the  information  source  for  all  ship  related  informa¬ 
tion.  Software  programs  can  either  be  re-structured  to  use  database  query  techniques  to  retrieve 
information,  or  the  database  can  be  designed  to  produce  the  required  input  files. 

The  use  of  a  general  ship  database  will  result  in  a  reduction  of  data  input  and  will  reduce  input 
errors.  It  also  ensures  that  up-to-date  information  is  used  by  all  users. 

In  order  to  design  the  database  system,  it  is  necessary  to  evaluate  the  information  needs  of  some 
of  the  more  important  software  programs.  This  will  ensure  that  the  database  contains  sufficient 
information  to  be  used  as  the  information  source  for  these  prorgrams. 

The  following  software  programs  are  described  and  evaluated  in  this  chapter: 

•  HECSALV:  Ship  Salvage  Engineering  Software.  Herbert  Engineering  Corporation,  San 
Erancisco,  CA  94111 

•  CARGOMAX:  Tanker  Loading  Software.  Herbert  Engineering  Corporation,  San  Fran¬ 
cisco,  CA  94111 

•  TACTICS:  Tactical  Stowage  and  Yard  Control  Planning.  Ship  Research  Inc.,  Oakland,  CA 
94612 

•  VISTA:  Vessel  Schedule  Tracking  and  Analysis.  Ship  Research  Inc.,  Oakland,  CA  94612 

•  VMS  (Vessel  Management  System):  Vessel  Scheduling  and  General  Information.  Chevron 
Shipping,  San  Francisco,  CA  94105 

•  Henry  Chen:  Vessel  Routing,  Ocean  Systems  Inc.,  Oakland,  CA 

Each  program  is  described  outlining  the  program  capabilities  and  the  program  structure.  The 
necessary  input  information  is  documented. 
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4.1  HECSALV 


The  HEC  Salvage  Engineering  Software  (HECSALV)  is  an  integrated  system  of  programs 
for  quick  salvage  response.  The  software  makes  it  possible  to  quickly  evaluate  damaged  conditions 
of  a  vessel.  This  includes  ground  reaction  and  strength  calculations  for  grounding  scenarios  and 
collision  cases. 

The  software  requires  the  input  of  the  vessel  hull  and  compartment  information  together  with 
the  midship  section,  stability  and  loading  information,  the  lightship  weight  distribution  and  down¬ 
flooding  locations. 

4.1.1  History 

Herbert  Engineering  Corporation  (HEC)  is  a  naval  architecture  and  marine  transportation  consult¬ 
ing  company  performing  a  variety  of  tasks  including  ship  design,  structural  analysis  and  salvage 
response.  In  order  to  facilitate  ship  design  contract  work,  several  computer  programs  have  been 
written  that  perform  standard  naval  architecture  calculations,  i.e.  hydrostatics,  intact  and  damage 
stability,  etc.  In  1986,  these  programs  have  been  combined  to  form  the  Ship  Design  Software 
(SDS). 

In  1988,  the  U.S.  Navy  decided  to  enhance  their  in-house  salvage  calculation  capabilities.  Based 
on  an  evaluation  of  existing  software  packages,  the  U.S.  Navy  selected  SDS  (developed  by  Herbert 
Engineering)  as  the  basis  for  the  improved  salvage  software.  The  U.S.  Navy  provided  funding  to 
improve  the  user  interface  of  SDS  and  to  add  additional  features  such  as  strength  calculations 
based  on  beam  theory  and  the  ability  to  analyse  simple  grounding  cases. 

The  funding  provided  by  the  U.S.  Navy  initiated  the  development  that  led  to  the  present 
version  of  HECSALV.  At  the  present  time,  HECSALV  is  used  by  the  USCG  and  the  US  Navy  for 
their  salvage  response  activities.  In  addition,  HECSALV  has  been  successfully  used  by  commercial 
and  military  interests  in  actual  salvage  situations. 

Some  of  the  Companies  and  organizations  that  have  purchased  HECSALV  include: 

•  Classification  Societies  -  ABS,  Lloyd’s  Register,  Germanischer  Lloyd 

•  Oil  Companies  -  Amoco,  BP  Chevron,  Conoco,  Exxon,  Mobil,  Shell,  UNOCAL, 

•  Organizations  -  David  Taylor  Research  Center,  National  Transportation  Safety  Board,  UC 
Berkeley,  USCG  Marine  Safety  Center,  USCG  Vessel  Engineering,  USCG  Naval  Academy, 
U.S.  Navy  Supervisor  of  Salvage,  Webb  Institute  of  Naval  Architecture 

4.1.2  Program  Description 

The  HECSALV  software  is  an  integrated  system  of  programs  designed  for  quick  salvage  response. 
It  enables  a  naval  architect  or  salvage  engineer  to  rapidly  evaluate  damaged  conditions  of  a  ship. 
Features  include  the  ability  to  analyze  the  intact  condition,  free-floating  damage  cases,  and  various 
types  of  stranding.  The  program  provides  estimates  of  damage  dependent  projected  oil  outflow, 
tidal  and  weather  effects  on  the  damaged  condition,  and  damaged  hull  girder  strength  and  deflec¬ 
tions. 

The  stranding  module  computes  ground  reaction  and  strength  calculations  for  various  ground¬ 
ing  scenarios,  including  the  effects  due  to  waves  and  tidal  changes.  The  section  modulus  editor 
provides  for  the  efficient  entry  of  the  hull  structure,  in  addition  to  calculations  based  on  reduced 
strength  from  damage  or  corrosion  to  individual  elements. 

The  software  has  the  ability  to  compute  the  actual  oil  outflow  based  on  hydrostatic  balance 
methodology  for  both  damage  stability  and  stranding  calculations.  This  feature  has  been  used  in 
a  study  for  the  U.S.  Coast  Guard  to  evaluate  different  tanker  designs  in  terms  of  the  projected  oil 
outflow  resulting  from  collisions  and  groundings,  [8]. 

The  software  has  the  following  main  features: 
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•  single  and  double  pinnacle  and  shelf  grounding  analysis 

•  strength  and  deflection  analysis  for  flooded  or  grounded  cases 

•  damaged  or  corroded  strength  analysis  based  on  actual  section  properties 

•  tidal  variation  analysis  for  grounded  cases 

•  actual  oil  outflow  based  on  vertical  extent  of  damage 

•  specification  of  partially  flooded  tanks  in  the  damaged  condition 

•  specification  of  internal  pressurization  for  damaged  compartments 

In  addition,  HECSALV  includes  programs  for  standard  naval  architecture  data  entry  and 
calculations.  These  programs  facilitate  the  entry  of  the  necessary  ship  information  for  performing 
salvage  calculations.  Program  functions  include: 

•  Hull  offset  entry 

•  Hydrostatics,  Bonjeans,  and  Cross  Curve  calculations 

•  Compartment  definition 

•  Compartment  volumes  and  centers  calculations 

•  Intact  trim  and  stability  calculations 

•  Shear  force  and  bending  moment  calculations 

4.1.3  Program  Structure 

The  HECSALV  software  consists  of  nine  separate  programs.  The  programs  interact  by  passing 
data  files  back  and  forth.  Understanding  of  interdepence  of  the  various  programs  and  the  overall 
data  flow  is  critical  to  the  effective  use  of  the  HECSALV  software.  Not  all  nine  programs  are 
required  for  every  design  evaluation  or  salvage  situation.  A  detailed  description  of  the  different 
programs  and  the  common  user  interface  can  be  found  in  [27] . 

Program  usage  can  be  divided  into  three  broad  categories: 

•  Development  of  data  files  for  future  use 

•  Analysis  (Data  files  previously  developed) 

•  Analysis  (Data  files  not  previously  developed) 

The  Hull  Offset  Entry,  Compartment  Entry,  Ship  Data  Entry,  Section  Modulus  Editor,  Hydro¬ 
static  and  Bonjean,  and  Cross  Curve  Programs  all  create  data  files  used  in  the  analysis  programs. 
If  this  data  has  been  previously  developed,  it  greatly  reduces  the  response  time  required  to  assess 
a  salvage  operation  or  perform  design  calculations. 

4.1.4  Data  Requirements  for  HECSALV 

The  following  information  has  to  be  provided  to  use  HECSALV. 

1.  General  Arrangement 

2.  Table  of  Offsets  or  Lines  Plan  (or  Frame  Scantling  drawings  if  offsets  and  lines  are  not 
available) 

3.  Midship  Section,  Construction  Profile  and  Plan  and  Shell  Expansion  for  structural  sections 
fore  and  aft  of  midships 

4.  Loading  Manual  and  Trim  and  Stability  Booklet 
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5.  Longitudinal  Strength  Verification  Calculations 

6.  Lightship  Weight  Distribution  Table  (or  Curve) 

7.  Downflooding  Locations 

8.  Draft  Mark  Locations 

9.  Allowable  Shear  Force  and  Bending  Moments  -  Class  approved  for  AT-SEA  and  IN-HARBOR 

HECSALV  uses  a  number  of  data  files  to  pass  information  between  the  different  program 
modules.  In  Appendix  C,  the  contents  of  the  main  data  files  is  described. 

4.2  CARGOMAX 

The  CARGOMAX  software  is  a  computerized  system  for  planning  and  evaluating  ship  loading. 
It  quickly  and  precisely  calculates  ship  stability  and  stress  characteristics  based  on  specified  loading 
conditions. 

The  program  is  developed  from  technical  information  that  reflects  the  physical  characteristics 
of  a  ship  or  class  of  ships.  This  information  includes  hydrostatic  data,  tankage  data,  allowable 
shear  forces  and  bending  moments,  and  light  ship  weight  distribution.  This  information  is  used  to 
develop  customized  input  screens  that  support  quick  and  efficient  entry  of  ship  loading  data. 

4.2.1  History 

In  order  to  facilitate  ship  design  contract  work,  software  has  been  developed  by  Herbert  Engineering 
to  calculate  the  intact  stability  and  stress  characteristics  for  different  loading  scenarios. 

User  experience  and  interest  from  various  clients  indicated  the  need  for  an  on-board  system  to 
monitor  ship  loading  based  on  stability  and  stress  criteria.  This  has  led  to  the  development  of  the 
CARGOMAX  software  in  1978. 

The  original  software  was  developed  for  HP-85  desktop  computers  and  was  subsequently  re¬ 
written  for  IBM  Personal  Computers  (PC).  Currently  version  3.0  of  CARGOMAX  is  commercially 
available. 

CARGOMAX  is  mainly  used  by  vessel  operators  to  monitor  the  actual  loading  process  in  order 
to  meet  stability  and  strength  requirements.  CHEVRON  Shipping  uses  the  CARGOMAX  load 
cases  as  input  to  the  developed  Vessel  Management  System  (VMS),  see  section  4.4. 

4.2.2  Program  Description 

The  CARGOMAX  software  is  a  software  system  to  evaluate  the  intact  stability  and  stress  charac¬ 
teristics  for  different  loading  conditions.  The  program  uses  a  menu  system  that  provides  access  to 
all  program  functions  with  simple  cursor  control.  These  functions  can  be  grouped  into  four  broad 
categories: 

•  File  Manipulation 

•  Tank  Data  and  Weight  Entry 

•  Calculations 

•  Display  and  Printing 

A  detailed  description  of  all  menu  options  and  data  entry  procedures  is  given  in  [18].  This  man¬ 
ual  also  describes  the  damage  stability  calculations  that  can  be  performed  using  the  CARGOMAX 
software. 
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4.2.3  Data  Requirements  for  CARGOMAX 

In  order  to  use  CARGOMAX  to  evaluate  different  loading  conditions  for  a  vessel,  hull  offsets  and 
compartment  information  for  the  vessel  has  to  be  available.  This  information  follows  the  format 
used  by  HECSALV,  described  in  section  4.1.4.  The  program  uses  the  following  data  files 

•  Load  Case  Data  .LC.  This  file  is  prepared  based  on  data  entry  performed  in  CARGOMAX 

•  Hull  Offsets  .HUL.  This  file  is  prepared  using  HECSALV. 

•  Compartment  Offsets  .CMP  k  CMA.  These  files  are  prepared  using  HECSALV. 

•  Compartment  Listing  .CML.  This  file  is  prepared  using  HECSALV. 

4.3  TACTICS 

The  TACTICS  program  is  a  workstation  based  computer  system  designed  to  support  tactical 
stowage  and  yard  control  planning.  Tactical  planning  is  the  day-to-day  planning  used  to  solve 
local  problems,  like  what  to  do  with  200  unexpected  rolls  in  a  nearly  full  yard.  It  differs  from 
strategic  planning  which  is  planning  used  to  solve  global  problems.  The  name  TACTICS  is  an 
acronym  for  TActical  Container  Terminal  Information  Control  System. 

4.3.1  History 

TACTICS  has  been  developed  by  Ship  Research  Inc.,  Oakland,  CA  for  American  President  Lines. 
The  program  is  used  for  tactical  stowage  and  yard  control  planning.  The  development  of  the 
TACTICS  Pilot  program  was  begun  in  June  1987,  and  the  first  version  was  installed  in  Kaohsiung 
in  February/March  1988. 

The  TACTICS  Pilot  program  was  designed  to  serve  two  purposes: 

•  provide  a  tool  to  ease  operational  problems 

•  serve  as  a  test  bed  to  establish  the  feasibility  and  appropriateness  of  the  TACTICS  philosophy 
for  improving  APC’s  operations. 

TACTICS  is  currently  used  by  American  President  Lines  for  tactical  stowage  and  yard  control 
planning.  Vessel  schedule  tracking  and  analysis  is  performed  using  VISTA,  a  subsystem  of  CAPS. 

4.3.2  Program  Description 

TACTICS  has  been  developed  for  the  Apple  Macintosh  computer.  The  program  therefore  uses  the 
Graphical  User  Interface  of  the  Macintosh.  Data  entry  is  performed  in  dialog  boxes.  The  program 
is  distributed  on  a  Local  Area  Network.  General  program  information  is  stored  on  the  file  server, 
whereas  ship  information  is  stored  on  the  individual  computers. 

The  program  consists  of  three  main  functions: 

•  Vessel  information  and  port  calls 

•  Yard  layout  and  container  storage 

•  Planning  and  recording  of  container  movement 

The  different  program  functions  are  described  in  detail  in  [34]  and  are  summarized  in  the 
subsequent  sections. 
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4. 3. 2.1  Vessel  Information  and  Port  Calls 

In  order  to  plan  stowage,  calculate  stability,  etc.,  it  is  necessary  to  define  the  vessel,  voyage  and 
port  call.  This  information  is  included  in  the  vessel-voyage-port  call  (VVP).  A  VVP  can  either 
be  downloaded  from  the  mainframe  or  created  directly.  It  contains  the  vessel  name,  the  voyage 
number  and  the  port  call  number. 

As  part  of  the  vessel  information,  a  hydrostatic  table  and  the  lightship  weight  distribution  has 
to  be  entered.  In  order  to  calculate  the  changes  in  the  weight  distribution  due  to  container  storage, 
the  center  of  gravity  of  each  container  row  has  to  be  entered. 

Tank  information  includes  the  weight,  the  tank  type  (ballast,  fuel,  fresh  water,  other)  and  tank 
geometry  (leg,  veg,  teg).  For  each  tank  the  weight  of  the  contents  has  to  be  entered. 

Ship  and  tank  information  in  conjunction  with  the  container  loading  is  used  to  perform  stability 
and  strength  calculations.  Results  of  these  calculations  are  displayed.  The  stability  display  includes 
the  GM  value,  strength  information,  drafts  and  attitude.  The  strength  display  shows  a  graph  of 
the  vessel’s  shear  and  bending  moment  distribution. 

The  inbound  stow  plan  for  a  vessel  is  downloaded  from  the  ETC  and  the  CAPS  program.  Both 
programs  are  operated  on  the  mainframe.  The  ETC  provides  the  inbound  stow  plan  and  CAPS 
provides  the  pre-plan  and  inbound  vessel  tankage  to  TACTICS. 

Once  a  stowage  plan  has  been  completed  and  conformed  in  TACTICS  it  has  in  general  to  be 
uploaded  to  the  mainframe  systems  ETC  and  CAPS. 

4. 3. 2. 2  Yard  Layout  and  Stowage  Plan 

The  container  yard  is  the  central  feature  of  TACTICS.  TACTICS  provides  a  means  of  keeping 
track  of  all  containers  within  the  yard.  It  allows  it  to  plan  and  track  movements  of  containers 
between  yard  areas,  from  the  yard  to  the  ship,  and  in  and  out  of  the  gate. 

The  yard  overview  shows  an  overhead  or  plan  view  of  the  yard,  identifying  different  physical 
yard  areas  (Transtainer,  Parking,  Pile-type)  and  logical  yard  areas  (Enroute,  outgate,  maintenance 
&  repair,  unknown).  For  each  area  type,  an  input  window  allows  it  to  specify  the  container  location 
for  each  specific  container. 

The  yard  space  can  be  organized  in  different  areas.  A  display  window  shows  the  occupied  and 
the  available  space  for  each  yard  period.  The  space  allocations  can  be  changed  using  a  set  layout 
command. 

4. 3. 2. 3  Planning  and  Recording  of  Container  Movements 

The  main  purpose  of  TACTICS  is  to  assist  in  planning  and  recording  the  movement  of  containers. 
In  TACTICS  containers  can  be  moved  from  vessel  to  yard,  yard  to  vessel,  within  the  yard  and 
vessel  to  vessel  in  a  number  of  ways.  Containers  can  be  moved  individually  or  as  a  group.  They 
can  be  moved  to  assigned  slot  positions  or  put  in  a  yard  area  without  a  specific  slot  location. 

Containers  are  selected  using  the  mouse  by  either  clicking  on  one  or  mor  containers  or  selecting 
a  group  of  containers  using  a  selection  rectangle.  The  selected  containers  are  moved  by  either 
clicking  on  the  desired  new  location  or  by  dragging  the  selected  containers  to  the  new  position. 

4. 3. 2. 4  Container  Attributes 

A  container’s  attributes  are  its  various  properties,  like  length,  height,  weight,  routing,  etc.  The 
task  of  vessel  and  yard  planning  amounts  to  deciding  where  to  put  each  container  based  on  some 
or  all  its  attributes. 

On  screen,  it  is  possible  to  control  the  display  of  the  container  attributes  based  on  the  actual 
task.  This  reduces  the  amount  of  un-necessary  information  on  the  screen  and  enhances  the  planning 
procedure. 


55 


4. 3. 2. 5  Searching  and  Operation  Planning 

The  use  of  search  lists  in  TACTICS  makes  it  possible  to  find  containers  based  on  on  or  many  of 
their  attributes.  This  enables  the  user  to  find  out  information  about  containers  in  the  system  as 
well  as  to  arrange  selected  containers  in  special  ways  to  arrange  their  stowing. 

All  of  the  container  attributes  can  be  used  to  direct  or  limit  a  search.  This  includes  container 
type,  dimensions,  status,  owner,  location,  load  vessel,  etc..  The  search  will  display  a  search  list 
window  that  contains  all  the  containers  that  satisfy  the  search  criteria.  The  appearance  and  sorting 
of  the  search  list  can  be  changed  by  selecting  the  fields  to  be  displayed  and  a  specific  sorting  order. 

Operation  planning  uses  the  notion  of  events  to  plan  future  operations.  An  event  in  TACTICS 
consists  of  a  group  of  planned  container  movements.  Using  events  makes  it  possible  to  specify  a 
whole  sequence  of  movements  for  a  container. 

For  each  event  an  event  name,  a  start  date  &  time  and  an  event  type  are  specified.  The 
event  type  distinguishes  between  Vessel  Activity,  (discharge  and  load)  and  Yard  and  General 
Activity,  (Shuffle  and  General). 


4.4  The  Vessel  Management  System  (VMS) 

As  part  of  an  ongoing  effort  to  computerize  ship  operations  to  improve  and  optimize  information 
flow  between  the  vessels  and  the  shore  facilities,  a  Vessel  Management  System  (VMS)  is  currently 
being  developed  by  Chevron  Shipping. 

The  system  is  intended  to  gather  vessel  specific  information,  improve  the  vessel  scheduling  and 
optimize  performance  by  implementing  a  better  information  flow  to  and  from  the  vessel. 

4.4.1  History 

The  development  of  the  Vessel  Management  System  that  contains  both  vessel  and  shore  modules 
is  based  on  the  general  strategy  to  improve  the  use  of  computers  onboard  ships. 

As  the  first  step  in  this  program.  Personal  Computers  (PC’s)  were  installed  on  each  vessel. 
Each  PC  contains  a  word  processor,  a  spreadsheet  and  technical  manuals.  It  was  intended  that 
the  availability  of  computers  would  be  an  incentive  for  the  vessel  crew  to  independently  develop 
computer  skills.  As  a  result  of  this  project  phase,  it  was  concluded  that  workshops  and  specific 
computer  training  courses  are  necessary  to  develop  computer  skills. 

In  the  second  phase  of  the  development,  more  specific,  ship  oriented  software  was  installed  on 
the  computers.  The  installed  software  was  a  commercial  package  intended  to  document  engine 
history  and  maintenance  and  contained  a  spare  parts  inventory. 

Based  on  this  system,  a  database  system  was  developed  for  the  documentation  of  vessel  oper¬ 
ations.  Data  originating  on  a  vessel  was  transferred  electronically  to  shore  and  stored  in  a  central 
database. 

In  addition  to  this  vessel  module,  a  shore  module  is  included  in  the  present  version  of  the 
Vessel  Management  System.  The  main  purpose  for  this  system  is  to  improve  and  optimize  vessel 
scheduling,  i.e.  matching  vessels  to  cargo.  In  the  following,  the  information  flow  for  the  vessel 
scheduling  procedure  is  outlined; 

•  Voyage  Order:  In  the  home  office,  a  preliminary  voyage  order  is  prepared  using  input  from 
Operations,  Accounting  and  Scheduling.  The  Planning  Group  reviews  this  voyage  order 
to  ensure  that  sufficient  bunker  capacities  are  available  and  that  possible  crew  changes  are 
arranged.  The  final  voyage  order  is  sent  to  the  vessel  using  e-mail. 

•  Voyage  Module:  The  voyage  module  contains  information  related  to  the  planned  and 
actual  vessel  route,  the  cargo  data  and  voyage  economics  contained  in  the  following  sub- 
modules: 

—  Voyage  Plan:  Lists  way  point  chains  and  the  current  sea  leg  plan. 


56 


—  Voyage  Orders:  Lists  the  itinerary,  the  cargo  orders,  the  bunker  orders,  the  charter 
party  information  and  port /canal  fees. 

-  Voyage  Monitor:  Lists  noon  position  report,  maneuvering  report,  operational  activi¬ 
ties,  plan  variance  analysis  and  the  upload  of  CargoMax  data. 

—  Voyage  Analysis:  List  the  plan  variance  log  and  the  plan  variance  analysis. 

-  Upload  CargoMax:  Lists  fuel  oil  data  for  engine  log. 

—  Voyage  Economics:  Lists  estimated  voyage  profits  and  losses. 

The  voyage  module  interacts  with  the  cargo  module  by  sharing  cargo  and  voyage  information. 

•  Cargo  Module:  The  cargo  module  lists  details  about  the  cargo  handling,  bunker  activities, 
operational  activities.  This  information  is  contained  in  several  sub-modules: 

—  Demurrage  &  Port  Activities:  Contains  port  activities  details  and  demurrage  cal¬ 
culations 

—  Deadfreight  Statement 

—  Cargo  Reconciliation:  List  B/L  cargo  figures,  ship/shore  differences,  VEF  qualifi¬ 
cations  and  cargo  reconciliations. 

—  Operational  Activities:  Lists  operating  delays. 

—  Bunker  Activities:  Lists  bunker  reconciliations,  fuel  cost  by  voyage,  fuel  cost  by 
date  and  the  bunker  history. 

-  Upload  CargoMax  Data 

•  Vessel  Reporting  Module:  Using  e-mail,  the  shipboard  data  is  sent  to  the  shoreside 
system  where  it  is  included  in  the  Vessel  Reporting  System  to  generate  reports  and  input 
for  the  voyage  accounting  system. 

-  Vessel  Reporting  System:  Contains  Master  Data  updates,  port/terminal  activities, 
operations  activities,  deadweight/deadfreight,  demurrage  calculations,  cargo  summaries, 
voyage  summaries,  voyage  analyses. 

—  Voyage  Accounting  System:  Contains  freight  revenue,  demurrage  revenue,  voyage 
costs  and  bunker  inventories. 

In  addition  to  the  vessel  scheduling,  the  VMS  is  also  intended  to  provide  more  detailed  in¬ 
formation  to  the  vessel  crew.  This  includes  information  about  the  revenue  basis  for  the  vessel 
operations,  the  daily  operating  costs  and  port  call  costs. 

Previously,  the  vessel  crew  was  not  informed  about  the  economic,  aspects  of  ship  operations.  It 
is  anticipated  that  the  increased  level  of  information  will  motivate  the  vessel  crew  to  reduce  delays 
and  reduce  the  overall  operating  expenses.  This  strategy  is  in  accordance  with  ongoing  efforts  for 
an  overall  quality  improvement  at  Chevron. 

The  Vessel  Management  System  is  also  used  to  improve  the  management  of  the  vessel’s  op¬ 
erating  expenses.  Responsibility  for  the  operating  expense  budget  is  given  to  the  vessel.  Cost 
estimates  for  each  aquisition  are  entered  into  the  system,  thus  creating  an  approximately  accurate 
and  up-to-date  operational  expense  budget. 

Many  of  the  forms  that  have  to  be  filled  out  to  document  vessel  operations  have  been  prepared 
for  electronic  input.  This  has  significantly  improved  efficiency. 

VMS  data  is  sent  to  the  home  offics  using  electronic  mail  (e-mail).  The  following  information 
can  be  sent: 


1.  Noon  position  report 

2.  Maneuvering 
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3  day  report 
end  of  port  call 


3.  Port  Activity 

4.  Port  Delays 

5.  Deadweight/deadfreight  calc 

6.  Ship/Shore  differences 

7.  Measurement  info  load/discharge 

8.  Plan  variance 

9.  Bunker  reconciliation 

10.  Operational  Activity 


end  of  port  call 
end  of  port  call 
end  of  loading 
end  of  load/discharge 
end  of  last  discharge 
end  of  voyage 
after  bunkering 
end  of  voyage 


The  information  is  appended  to  a  regular  e-mail  message.  At  the  home  office  the  message  is 
automatically  detected,  converted  to  a  suitable  file  format  and  included  into  VMS. 


4.4.2  Operational  Experiences 

At  the  present  time,  the  Vessel  Management  System  is  installed  on  about  2/3  of  Chevron’s  tanker 
fleet.  The  installation  process  consists  largely  of  crew  training.  According  to  the  VMS  project 
management,  the  implementation  and  crew  training  phase  of  the  project  by  far  exceeds  the  actual 
software  development. 

Originally,  the  crew  training  was  performed  in  compact,  on-shore  workshops  combined  with  on¬ 
board  tutorials.  The  training  courses  were  scheduled  as  part  of  the  crew’s  vacation  time,  resulting 
in  significant  time  gaps  between  the  training  courses  and  the  practical  application  during  vessel 
operations. 

In  a  modified  procedure,  the  computer  training  is  conducted  on-board  of  the  vessel  during  a 
voyage.  Individual  training  sessions  are  scheduled  with  crew  members  during  the  off-duty  hours. 
This  approach  is  judged  to  be  more  effective  than  the  on-shore  workshops.  However,  it  is  crucial 
to  coordinate  vacation  schedules  with  the  on-board  training  courses.  Vacation  time  for  a  crew 
member  directly  following  a  training  course  will  prevent  the  application  of  the  gained  computer 
skills.  Short  (3  day),  on-shore  seminars  have  been  implemented  for  crew  members  returning  from 
a  vacation  to  refresh  the  computer  skills  and  the  knowledge  of  the  Vessel  Management  System 
(VMS). 

4.4.3  Information  Contents  of  VMS 

Data  entry  screens  have  been  developed  for  the  Vessel  Management  System.  Some  data  is  entered 
only  once  for  each  vessel,  other  data  is  entered  after  each  port  call,  etc.  The  information  that 
needs  to  be  entered  for  each  screen  is  listed  in  Appendix  D. 
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Chapter  5 


Development  of  CAIP  Format 


5.1  Introduction 

One  of  the  main  reasons  that  has  lead  to  the  development  of  several  ship  information  databases 
designed  to  contain  the  results  of  vessel  structural  surveys  has  been  the  introduction  of  Critical 
Area  Inspection  Plans  (CAIP).  The  requirement  for  operators  to  document  structural  failures  and 
to  clearly  identify  problem  areas  and  trends  has  led  to  an  increased  use  of  electronic  databases. 

This  chapter  documents  the  process  resulting  in  a  preferred  format  for  Critical  Area  Inspection 
Plans  that  will  be  used  as  the  output  definition  of  the  SSIIS  prototype  CAIP  reporting  module  . 
In  order  to  develop  a  clear  understanding  of  Critical  Area  Inspection  Plans,  the  background  for 
the  definition  of  the  CAIP  and  the  format  and  information  contents  as  defined  by  the  U.S.  Coast 
Guard  in  [15]  are  documented. 

The  format  and  structure  of  several  Critical  Area  Inspection  Plans  submitted  to  the  U.S.  Coast 
Guard  by  various  operators  are  evaluated.  Based  on  this  evaluation  and  on  the  experience  made 
by  Coast  Guard  inspectors  in  using  the  Critical  Area  Inspection  Plans  a  detailed  CAIP  format  is 
described  that  is  intended  to  improve  the  overall  usefulness  of  Critical  Area  Inspection  Plans. 


5.2  U.S.  Coast  Guard  Definition  of  Critical  Area  Inspec¬ 
tion  Plans  (CAIP) 

This  section  documents  the  contents  of  the  Navigation  and  Vessel  Inspection  Circular  No.  15-91, 
[15],  issued  by  the  U.S.  Coast  Guard  in  Oct.  1991.  It  is  the  purpose  of  this  Circular  to  provide 
guidance  to  the  marine  industry  for  the  development,  use,  and  implementation  of  CAIP’s.  The 
Circular  is  intended  to  provide  a  performance  standard  for  CAIP’s  rather  than  detailed  instructions 
for  the  development  of  these  plans. 


Background 


The  following  points  document  the  background  and  intentions  of  CAIP’s  as  outlined  in  [15]; 

•  A  CAIP  is  a  management  tool  that  serves  to  track  the  historical  performance  of  a  vessel, 
identify  problem  areas,  and  provide  greater  focus  to  periodic  structural  examinations.  The 
preparation  of  a  CAIP  is  the  primary  responsibility  of  the  vessel  owner  or  operator.  The 
CAIP  is  part  of  an  integrated  management  plan  for  achieving  an  adequate  level  of  structural 
monitoring,  maintenance,  and  repair. 
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•  The  decision  to  require  a  CAIP  on  a  single  vessel  or  on  an  entire  class  of  vessels  may  be 
based  on  the  vessel’s  history,  its  service,  or  even  the  climatology  of  the  trade  route. 

•  The  development  and  maintenance  of  a  CAIP  is  intended  to  result  in  an  increased  involvment 
of  the  vessel’s  management  in  the  processe  of  finding  a  solution  to  identified  structural  and/or 
maintenance  problems.  It  is  the  ultimate  goal  of  a  CAIP  to  address  the  cause  of  problems, 
not  merely  the  symptoms. 

•  Definition  of  terms  used  in  CAIP’s: 

1.  Active  repair  areas:  areas  that  continue  to  experience  active  or  recurring  cracking 
in  the  oil/ watertight  envelope  or  that  affect  the  structural  integrity  of  the  vessel. 

2.  Critical  inspection  areas:  areas  that  incorporate  all  present  and  previous  active 
repair  areas  including  past  active  areas  that  require  continued  monitoring.  Other  areas 
may  be  deemed  critical  based  on  class  problems  or  assessment  of  the  structure  through 
appropriate  calculations  and  analysis. 


Discussion 


In  [15]  the  intended  purpose,  expectations  of  the  U.S.  Coast  Guard  based  on  the  implementation 
of  the  CAIP  requirement,  the  CAIP  development  process  and  guidelines  for  CAIP  surveys  are 
discussed.  In  the  following,  these  points  are  summarized: 

•  The  cause  of  all  structural  failures  must  be  addressed.  Determining  the  causes  of  Class  1 
structural  failures,  and  other  structural  failures,  as  defined  in  enclosure(l)  of  [15],  is  critical 
to  the  correct  selection  of  an  appropriate  repair  methodology. 

•  CAIP’s  are  intended  to  be  the  method  used  by  vessel  management  to  document  and  track 
structural  failures.  In  this  capacity,  CAIP’s  will  assist  surveyors,  inspectors  and  the  vessel’s 
crew  in  ensuring  the  vessel  is  properly  inspected  and  maintained.  Within  the  CAIP,  the 
surveyor,  inspector,  or  crew  will  be  able  to  find  detailed  information  on  the  vessel’s  fracture 
history,  corrosion  control  systems,  and  previous  repairs.  The  CAIP  will  also  contain  a  record 
and  evaluation  of  repairs  to  the  vessel’s  fractures.  It  is  critical  to  know  what  temporary  or 
permanent  repairs  have  been  successful  in  the  past.  The  evaluation  of  permaneni  repairs 
and/or  design  modifications  is  important  to  the  vessel’s  overall  fitness. 

•  The  CAIP  format  presentation  is  at  the  discretion  of  the  company’s  management.  The 
information  in  the  CAIP  should  be  clear,  up-to-date,  and  easy  for  someone  not  familiar  with 
the  vessel  to  understand. 

•  CAIP’s  will  be  developed  by  the  vessel’s  owner  or  operator  when  required  in  writing  by  the 
appropriate  Coast  Guard  authority.  The  designated  authority  will  outline  the  existing  or 
potential  problem  that  necessitates  a  CAIP  being  developed.  In  addition,  an  appropriate 
policy  letter  will  be  promulgated,  if  necessary. 

CAIP’s  will  be  reviewed  when  they  are  initially  developed.  The  review  process  will  be 
specified  in  the  implementing  letter. 

CAIP’s  should  be  updated  anytime  the  vessel  experiences  a  new  Class  1  or  2  fracture,  a 
recurrence  of  the  original  problem,  a  modification,  or  a  survey. 

In  order  to  remove  areas  from  active  monitoring,  the  owner  or  operator  has  to  submit  a 
letter  request  together  with  the  documentation  contained  in  the  vessel’s  CAIP  supporting 
the  change. 

•  Surveys  are  an  integral  part  of  the  CAIP.  Survey  reports  should  include  the  basic  information 
listed  in  enclosure  (4)  contained  in  [15]. 
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Implementation 


The  implementation  of  a  CAIP  requirement  for  a  vessel  is  to  be  closely  monitored.  OCMI’s 
(Officer  in  Charge  of  Marine  Inspections)  are  encouraged  to  take  a  very  restrictive  position  regard¬ 
ing  whether  to  issue  a  Certificate  of  Inspection  to  a  vessel  that  has  not  complied  with  a  requirement 
for  a  CAIP. 

CAIP’s  have  applicability  for  use  on  all  vessels  as  a  means  of  tracking  and  recording  structural 
history.  Even  when  not  required,  all  owners  and  operators  should  be  advised  to  incorporate  the 
principles  of  CAIP’s  into  their  management  philosophy. 

5.2.1  Enclosure  (1)  to  NVIC-15-91 

Classification  of  Structural  Failures 


Definitions 

1.  Oil/ watertight  envelope  -  the  strength  deck,  side  shell  and  bottom  plating  of  a  vessel,  in¬ 
cluding  the  bow  and  stern  rakes  of  barges. 

2.  Internal  strength  members  -  the  center  vertical  keel;  deep  web  frames  and  girders;  transverse 
bulkheads  and  girders;  side,  bottom  and  underdeck  lognitudinals;  longitudinal  bulkheads; 
and  bilge  keels. 

3.  Buckle  -  any  deformation  in  the  oil/ watertight  envelope  whereby  the  adjoining  internal 
structural  members  are  also  bent  to  such  an  extent  that  structural  strength  has  been  lost. 


Classifications 


Three  classes  of  structural  failures  are  defined: 

•  Class  1  Structural  Failure: 

A  fracture  that  occurs  during  normal  operating  conditions  (i.e.,  not  as  the  result  of  a  ground¬ 
ing,  collision,  or  other  casualty  damage),  that  is 

1.  A  fracture  of  the  oil/watertight  envelope  that  is  visible  and  of  any  length,  or  a  buckle, 
that  has  either  initiated  in  or  has  propagated  into  the  oil/ watertight  envelope  of  a 
vessel;  or 

2.  a  fracture  10  feet  or  longer  in  length  that  has  either  initiated  in  or  has  propagated  into 
an  internal  strength  member. 

•  Class  2  Structural  Failure: 

A  fracture  less  than  10  feet  in  length,  or  a  buckle,  that  has  either  initiated  in  or  has  propa¬ 
gated  into  an  internal  strength  member  during  normal  operating  conditions. 

•  Class  3  Structural  Failure: 

A  fracture  or  buckle  that  occurs  under  normal  operating  condition  that  does  not  otherwise 
meet  the  defintion  of  either  a  Class  1  or  Class  2  structural  failure. 
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5.2.2  Enclosure  (2)  to  NVIC-15-91 

Critical  Areas  Inspection  Plans  Performance  Elements 


1.  Executive  Summary  -  this  overview  should  be  easy  to  read  and  give  an  overall  outlook  on  the 
vessel  and  the  remainder  of  the  plan.  This  summary  should  include  a  list  of  the  designated 
crtical  inspection  areas. 

2.  Vessel  Particulars 

a.  Name,  Official  Number 

b.  Vessel  Design  Class 

All  other  vessel  particular  information  can  be  found  on  the  Certificate  of  Inspection 

(COI). 

3.  Historical  Information. 

a.  Structural  Failures 

(a)  Type 

(b)  Location 

(c)  Method  of  repair 

b.  Vessel  Structural  Modifications 

(a)  Major  structural  modifications 

(b)  Detail  modifications 

This  section  is  intended  to  be  for  those  areas  where  the  repair  has  been  successful  with 
no  recurrence. 

4.  Active  Repair  Areas. 

a.  Structural  Failures 

(a)  Type 

(b)  Location 

(c)  Method  of  repair 

(d)  Number  of  occurrences 

(e)  Date  of  most  recent  repair 

b.  Vessel  Structural  Modifications 

(a)  Major  structural  modifications 

(b)  Detail  modifications 

c.  Structural  Analyses  Completed/Pending 

(a)  Results  of  completed  analyses  kept  on  board 

(b)  Implementation  plan  for  recommended  corrective  action 

d.  Trends 

(a)  Description  of  method  used  to  determine  trends,  i.e.,  gaugings,  renewals,  coating 
and  anode  systems,  etc. 

(b)  Results 

Sections  3  and  4  above  may  be  organized  in  many  different  ways  depending  on  the  volume 
of  the  information  and  the  availability  of  other  data  management  systems.  It  is  important 
that  the  information  be  presented  so  it  can  be  easily  interpreted  by  company  maintenance 
representatives,  classification  society  surveyors,  and  Coast  Guard  inspectors. 
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5.  Structural  Inspections 

a.  Critical  Area  Inspection  Intervals 

(a)  Annual/semi-annual 

b.  Records  of  Inspections 

(a)  Internal 

(a)  Tank 

(b)  Date 

(c)  Method 

(d)  Inspected  by  (USCG,  ABS,  Company) 

(e)  Previous  inspection  date 

(f)  Problems  noted 

(b)  A  vessel  log  should  be  maintained  indicating  the  person  or  persons  who  performed 
the  inspection 

(c)  External  surveys  (hull,  bilge  keels,  etc.) 

(a)  Date 

(b)  Inspection  method,  i.e.,  drydock,  underwater  survey 

(c)  Inspected  by  (USCG,  ABS,  Company) 

(d)  Previous  inspection  date 

(e)  Problems  noted 

6.  Tank  Coating  Systems, 

a.  Type 

b.  Last  Renewed 

c.  Planned  Renewal 

d.  Present  Condition  and  Percent  Failure 

7.  Critical  Areas  Inspection  Plan  Update 

a.  Internal  Company  Review 
(a)  Frequency 

The  use  of  diagrams  and  vessel  plans  to  illustrate  fractures  and  problem  areas  is  highly 
encouraged. 

5.2.3  Enclosure  (4)  to  NVIC-15-91 

Critical  Areas  Inspection  Plans  Performance  Elements 

Survey  reports  should  contain  the  following  information: 

1.  Survey  Particulars 

a.  Vessel  name 

b.  Scope  of  survey 

(a)  Yearly  cargo  block  (entire  or  partial) 

(b)  Active  repair  area 

(c)  Any  other  area  required  to  be  inspected 

c.  Local  OCMI  notified 
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(a)  MSO 

(b)  Date  of  letter 

2.  Survey  Participants 

a.  Names 

b.  Organizations 

c.  Qualifications 

3.  Survey  Results 

a.  Tanks  entered  (or  critical  area  checked) 

b.  Tank  cleanliness 

c.  Method  of  inspection 

d.  Comment  of  overall  condition  of  the  tanks 

e.  If  coated,  percent  of  coating  breakdown  (if  applicable) 

f.  Fractures  noted 

(a)  Location 

(b)  Dimensions 

(c)  Suspected  cause 

(d)  Class/ USCG  notified 

g.  Other  damage/conditions  noted 

(a)  Deformations 

(b)  Wastage 

For  tank  vessels  the  Guidance  Manual  for  the  Inspection  and  Condition  Assessment  of  Tanker 
Structures,  [36],  contains  sample  forms  that,  if  properly  filled  out,  could  constitute  the  survey 
report. 

A  similar  document  has  been  published  by  the  International  Association  of  Classification  So¬ 
cieties  (lACS)  for  Bulk  Carriers,  [22].  The  assessment  and  repair  of  the  hull  structure  of  bulk 
carriers  is  outlined  in  detail  including  sketches  of  frequent  failures  and  possible  repair  solution. 
This  information  can  be  used  to  help  in  the  development  of  repair  representations  in  a  future 
SSIIS. 

5.3  Structural  Failures  Reporting  Requirements 

Chapter  5  of  the  Marine  Safety  Manual  (MSM)  contains  classifications  and  definitions  of  struc¬ 
tural  failures,  describes  the  notification  procedures  for  the  different  failure  classes  and  outlines  the 
documentation  requirements  for  structural  failures,  [14]. 

For  Class  1  structural  failures  on  U.S.  Flag  vessels  the  vessel’s  operator  is  required  to  submit 
to  the  classification  society  and  to  the  OCMI  (Officer  in  Charge  of  Marine  Inspection)  a  detailed 
description  of  the  failure  and  a  proposal  for  both  temporary  and  permanent  repairs.  In  addition, 
the  operator  has  to  provide  the  past  history  of  similar  failure  and  the  results  of  any  past  studies 
related  to  the  type  of  failure  that  has  occured.  If  this  information  is  not  available,  the  company  is 
required  to  perform  an  analysis  of  the  failure  and  submit  the  results  to  the  OCMI. 

The  submitted  information  including  recommendations  from  the  respective  classification  soci¬ 
ety  is  evaluated  by  the  OCMI  to  determine  an  appropriate  repair. 

Operational  restrictions  may  be  placed  on  a  tank  vessel  pending  the  completion  of  the  required 
permanent  repair.  For  any  temporary  repair,  the  operator  is  required  to  submit  calculations  that 
show  that  the  vessel  can:  1)  safely  load  other  intact  cargo  tanks  and  2)  safely  operate  with  the 
affected  cargo  tank  either  ballasted  or  empty. 
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Vessels  with  Significant  Structural  Problems  may  be  subjected  to  operating  restrictions, 
required  to  change  service  to  a  more  moderate  climate  or  phased  out  of  service.  A  list  of  these 
Special  Attention  Vessels  is  maintained  and  provided  to  the  field. 

For  Class  2  and  Class  3  Structural  Failures  permanent  repairs  of  non-critical  failures  can  be 
delayed  until  the  next  scheduled  shipyard  repair  period  provided  the  operator  provides  sufficient 
information  to  demonstrate  that  the  failures  are  not  critical  and  will  not  propagate. 

Fig.  (5.1)  shows  a  flow  chart  for  the  documentation  of  structural  failures  and  the  submission  of 
reports.  The  chart  shows  the  different  procedures  depending  on  the  classification  of  the  structural 
failure.  In  addition  the  different  Coast  Guard  divisions  involved  in  the  process  are  clearly  identified. 


5.4  Evaluation  of  CAIP  Report  Examples 

CAIP  reports  are  routinely  sent  to  the  U.S.  Coast  Guard  headquarters.  Several  reports  from 
different  companies  are  reviewed.  This  review  is  intended  to  document  the  differences  and  common 
elements  of  present  Critical  Area  Inspection  Plans  and  to  develop  improved  format  recommendation 
for  CAIP  reports. 

For  each  reviewed  CAIP  report,  a  general  description  is  given,  outlining  the  approach,  infor¬ 
mation  contents  and  structure  of  the  CAIP  report.  Then,  the  report  is  evaluated  for  its  compliance 
with  the  list  of  Critical  Area  Inspection  Plans  Performance  Elements  outlined  in  enclosure  (2)  of 
the  Navigation  and  Vessel  Inspection  Circular  (NVIC)  No.  15-91,  [15]. 

The  CAIP  report  review  are  intended  to: 

•  determine  the  information  content  of  each  CAIP  report 

•  evaluate  the  adherence  of  each  report  to  the  list  of  performance  elements  stated  in  enclosure  2 
of  the  Navigation  and  Vessel  Inspection  Circular  15-91,  [15]. 

•  conclude  on  the  effectiveness  of  each  CAIP  report  to  achieve  the  goals  that  have  led  to  the 
implementation  of  the  Critical  Area  Inspection  Plan  requirement,  as  stated  in  the  Navigation 
and  Vessel  Inspection  Circular  15-91,  [15]. 

5.4.1  Vessel  A 

5. 4. 1.1  Description 

The  Critical  Area  Inspection  Plan  for  the  Vessel  A  follows  the  NVIC  format  very  closely.  The 
vessel  particulars  are  listed  including  a  general  arrangement  drawing,  a  list  of  tanks,  a  machinery 
description  and  international  load  lines. 

A  summary  of  past  structural  failures  is  given.  For  Class  1,  Class  2  and  pattern  type  Class  3 
failures,  the  fracture  locations,  repair  information  is  listed  indicating  repair  success  where  applica¬ 
ble. 

A  detailed  table  of  structural  failures  is  listed,  documenting  for  each  tank  the  failure  type, 
location,  class,  repair/modification  and  the  number  of  cracks  in  two  successive  structural  surveys. 
Representative  fracture  types  and  fracture  locations  are  shown  on  attached  drawings.  Reference 
is  made  to  the  individual  inspection  reports  for  additional  information.  A  nomenclature  for  the 
keywords  used  in  the  failure  table  is  provided. 

Present  and  past  Active  Repair  Areas  are  listed.  The  areas  are  listed  by  tanks  and  a  short 
description  of  the  location  is  given.  A  list  of  structural  inspections,  including  the  next  scheduled 
drydock  survey,  is  given.  Inspection  reports  and  inspection  companies  are  listed. 

The  tank  coating  system  is  summarized,  describing  the  original  coating  system  and  coating 
repair.  In  addition,  a  coating  maintenance  plan  is  summarized. 

Attachment  1  of  the  Critical  Area  Inspection  Plan  for  the  Vessel  A  includes  any  revisions  or 
additions  deemed  necessary  following  the  April  1992  Visual  Survey  of  the  Vessel  A. 
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The  format  of  the  table,  describing  the  structural  failures  and  the  repair  plan,  has  been  changed. 
For  each  tank  the  location,  a  description  of  the  failure,  the  size,  the  class  and  the  repair  plan  is 
listed. 

An  updated  summary  of  the  inspection  schedule  and  the  coating  system  is  listed. 

5.4.1. 2  CAIP  Performance  Elements  Evaluation 

Executive  Summary 

No  Executive  Summary  included. 


Vessel  Particulars 

General  Arrangement,  tank  description.  Machinery  and  load  lines  are  summarized.  The  list  of 
vessel  particulars  includes  the  following  information: 

•  Name 

•  Hull  No. 

•  Coast  Guard  ID 

•  ABS  ID 

•  Vessel  Class 

•  Builder 

•  Delivery 

•  DWT 

•  Presence  of  SBT 

•  Presence  of  IGS 

•  Presence  of  COW 

•  Presence  of  Heating  Coils 

•  Cargo  Type 

Historical  Information 

Summary  of  Class  1,  Class  2  and  Class  3  failures.  For  Class  1,  Class  2  and  pattern  type  Class  3 
failures,  a  short  summary  of  the  cracking  problem,  the  repair  solution  and  an  assessment  of  the 
repair  success  is  given.  No  graphical  representation  is  available. 

The  tabular  listing  of  failures  lists  failure  types,  location,  class,  repair/modification  and  the 
number  of  cracks  found  in  different  surveys  for  the  individual  tanks.  Due  to  the  lack  of  a  graphical 
representation,  this  information  is  not  very  informative. 

Vessel  structural  modifications  are  not  listed  separately  and  no  drawings  for  detail  modifications 
are  presented. 

Active  Repair  Areas 

The  report  lists  the  active  repair  areas  for  each  relevant  tank.  It  does  not  document  individual 
structural  failures  for  these  areas.  This  constitutes  a  significant  difference  from  the  NVIC  format. 
No  graphical  representation  of  the  active  repair  areas  is  given. 

No  structural  modifications  for  the  active  repair  areas  are  listed.  No  mention  is  made  of 
completed  or  pending  structural  analysis.  No  trends  for  the  structural  failures  in  the  active  repair 
areas  are  documented. 
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structural  Inspections 

The  documentation  of  structural  inspections  states  the  inspection  schedule  for  drydock  surveys, 
structural  surveys  by  ABS  and  USCG  and  owner’s  inspections.  In  addition,  the  date  and  inspection 
company  for  each  inspection  report  are  listed.  No  summary  of  the  inspections  is  presented. 

Tank  Coating  Systems 

The  original  coating  system  is  summarized  and  coating  repairs  are  documented.  A  coating 
maintenance  plan  outlines  the  planned  renewal.  No  summary  of  present  condition  and  coating 
failure  percentage  is  given. 

Critical  Areas  Inspection  Plan  Update 

A  CAIP  attachment  is  included  that  documents  revisions  and  additions  to  the  original  CAIP 
based  on  the  April  1992  Visual  Survey.  The  attachment  uses  a  modified  format  for  the  tabular 
representation  of  failures  that  improves  the  description  of  the  failure.  No  graphical  representation 
of  the  failure  distribution  on  the  vessel  in  given. 

5.4. 1.3  Summary 

The  Critical  Area  Inspection  Plan  for  the  Vessel  A  follows  in  its  structure  very  closely  the  format 
outlined  in  enclosure  2  of  the  Navigation  and  Vessel  Inspection  Circular  15-91,  [15].  The  lack  of 
graphical  representations  of  failure  distributions  in  the  vessel  and  the  minimal  documentation  of 
failures  in  active  repair  areas  constitute  a  significant  limit  in  the  usefulness  of  this  CAIP. 


5.4.2  Vessel  B 

5. 4. 2.1  Description 

The  Critical  Area  Inspection  Plan  for  the  Vessel  B  contains  a  very  short  description  of  the  vessel 
indicating  the  name  the  class  and  the  number  of  cargo  tanks.  In  addition  a  general  arrangement 
plan  is  shown  that  contains  the  main  vessel  dimensions  and  additional  information. 

A  summary  of  the  structural  history  with  respect  to  each  critical  inspection  area  is  given. 
Sketches  of  typical  fractures  are  included.  A  list  of  Critical  Areas  is  included.  For  each  area  the 
failures  and  the  repair  and  modifications  are  described. 

An  inspection  and  repair  summary  is  presented  and  the  as-built  and  current  tank  coating 
systems  are  described.  The  inspections/surveys  used  for  the  Critical  Area  Inspection  Program  are 
listed  and  the  means  for  tracking  trends  are  summarized. 

5.4. 2. 2  CAIP  Performance  Elements  Evaluation 

Executive  Summary  The  plan  summary  lists  the  critical  inspection  areas  and  summarizes  the 
most  recent  inspection  findings. 

Vessel  Particulars 

In  a  general  description  the  vessel  name,  the  Official  Number,  the  class,  the  type  of  framing, 
the  number  of  cargo  and  ballast  tanks  are  summarized.  In  addition,  a  general  arrangement  plan 
is  provided  that  lists  the  following  information: 

•  LOA,  LBP 

•  Molded  Beam 

•  Depth,  Molded  to  Main  Deck  at  Side 

•  Current  Summer  Load  Line  Draft 

•  Current  Summer  Deadweight 
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•  Lightship  Weight 

•  Gross  Registered  Tonnage 

•  Net  Registered  Tonnage 

•  Builder 

•  Hull  Number 

•  Year  of  Delivery 

•  Official  Number 

Historical  Information 

The  structural  history  is  provided  with  respect  to  each  crictical  inspection  area.  For  each  area 
the  failures  are  described  including  sketches  of  typical  failures.  In  most  cases,  the  repair  method 
is  described  and  un-successful  repairs  are  identified. 

Active  Repair  Areas 

A  summary  of  the  Critical  Area  Inspection  Plan  for  the  Vessel  B  is  presented  that  lists  for 
each  critical  area  the  location,  the  inspection  procedure  and  the  inspection  frequency. 

Structural  Inspections 

The  inspection  history  is  documented,  listing  the  inspection  date,  the  location,  a  description 
of  the  survey  and  repairs  and  a  reference  report  for  each  inspection. 

Tank  Coating  Systems 

The  as-built  and  current  tank  coating  systems  are  listed.  For  each  tank  the  tank  type  (cargo 
or  ballast  or  both),  the  as-built  coating  systems,  the  current  coating  system  and  the  last  coating 
data  are  summarized. 

Critical  Areas  Inspection  Plan  Update 

It  is  stated  that  the  results  of  periodic  surveys  will  be  used  to  update  the  CAIP  report. 


5.4. 2. 3  Summary 

The  Critical  Area  Inspection  Plan  report  for  the  Vessel  B  follows  in  its  structure  very  closely  the 
format  outlined  in  enclosure  2  of  the  Navigation  and  Vessel  Inspection  Circular  15-91,  [15].  The 
representation  of  the  structural  history  is  detailed  and  includes  sketches  of  typical  failures.  A 
graphical  representation  of  the  failure  distribution  in  the  vessel  would  add  clarity. 

The  documentation  of  the  critical  inspection  areas  is  not  sufficient.  The  critical  inspection 
areas  are  listed,  but  no  failure  information  or  documentation  of  repairs/modifications  is  provided. 

5.4.3  Vessel  C 
5.4. 3.1  Description 

The  Critical  Area  Inspection  Plan  report  for  the  Vessel  C  contains  a  short  description  of  the  main 
vessel  particulars.  A  top  view  of  the  vessel  shows  the  location  of  all  tanks. 

As  part  of  the  description  of  the  vessel’s  structural  history,  plans  are  provided  that  indicate 
areas  of  high  stress  concentrations  that  are  most  likely  to  show  fatigue  failures. 

The  summary  of  the  fracture  history  contains  graphical  output  from  ARCO’s  proprietary 
fracture  database  showing  the  longitudinal  and  transverse  distribution  of  fractures  for  different 
inspections.  The  most  common  fractures  are  shown  in  several  illustrations.  The  type  of  repair  is 
described.  Some  structural  modifications  are  illustrated. 
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A  summary  of  fractures  categorized  according  to  severity  and  structural  member  shows  that 
most  fractures  occur  in  longitudinals. 

The  tank  coating  history  is  documented.  For  each  tank  the  tank  protection  system,  the  coating 
condition,  the  last  inspection  date  and  the  last  renewal  date  are  listed. 

The  external  surveys  that  have  taken  place  since  the  CAIP  requirement  for  the  Vessel  C  was 
issued  are  summarized.  The  Inspection  and  CAIP  update  schedule  conclude  the  Critical  Area 
Inspection  Plan  report  for  the  Vessel  C.  Appendix  I  contains  a  sample  of  a  typical  survey  report. 
Appendix  II  explains  how  to  record  fractures  and  contains  the  Fracture  Record  Sheets  that  are 
used  to  report  the  fractures  and  to  update  the  Hull  Fracture  Database.  Additional  appendixes 
contain  the  survey  reports  that  have  taken  place  since  the  plan  was  issued. 

5.4. 3. 2  CAIP  Performance  Elements  Evaluation 
Executive  Summary 

No  executive  summary  is  contained  in  the  Critical  Area  Inspection  Plan  report  for  the  Vessel 

C. 

Vessel  Particulars 

The  location  of  all  tanks  is  shown  in  a  top  view.  In  addition,  the  following  vessel  particulars 
are  listed: 

•  Builder 

•  Delivery  Date 

•  Hull  No. 

•  Class 

•  LOA 

•  LBP 

•  SLL 

•  Beam,  molded,  MS 

•  Depth,  molded 

•  Summer  DWT 


Historical  Information 

A  short  summary  of  the  vessel  history  is  provided  indicating  that  no  major  structural  modifi¬ 
cations  have  been  made  to  the  vessel  during  its  sailing  life. 

The  results  of  a  structural  study  to  determine  details  with  high  stress  concentrations  are 
included  as  part  of  the  structural  history.  Illustrations  of  these  details  indicating  the  problem  areas 
are  provided.  These  illustrations  are  very  informative  and  document  possible  crack  locations. 

As  part  of  the  documentation  of  the  fracture  history,  the  longitudinal  and  transverse  distri¬ 
bution  of  fractures  in  the  hull  is  shown  for  the  different  surveys.  In  addition,  the  main  fractures 
are  described  and  are  shown  in  detail  drawings.  The  repair  method  is  stated.  Examples  of  detail 
modifications  to  reduce  stress  concentrations  are  included. 

In  order  to  summarize  the  fracture  history,  the  failures  are  listed  according  to  the  structural 
member  and  the  severity.  This  information  is  also  presented  graphically. 

Active  Repair  Areas 

No  active  repair  areas  are  mentioned.  No  information  identifying  problems  in  active  repair 
areas  is  included  in  the  report. 
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structural  Inspections 

A  short  list,  indicating  the  external  surveys  performed  since  the  CAIP  requirement  for  the 
Vessel  C  was  issued,  is  presented  showing  the  survey  date,  the  inspection  method,  the  inspectors 
names  and  remarks  about  the  survey  findings  and  work  performed. 

Tank  Coating  Systems 

The  tank  coating  history  lists  for  each  tank  the  tank  protection,  the  coating  condition  (new, 
good,  fair,  poor),  the  last  inspection  date,  remarks  and  the  last  renewal  date. 

Critical  Areas  Inspection  Plan  Update 

The  CAIP  report  indicates  the  intention  to  provide  updates  of  the  fracture  history  after  the 
biennial  shipyard  overhaul.  In  addition,  a  complete  report  of  the  fractures  detected,  along  with 
repairs  and/or  structural  modifications  will  be  incorporated  in  an  appendix  to  the  CAIP. 

5.4. 3. 3  Summary 

The  Critical  Area  Inspection  Plan  report  for  the  Vessel  C  contains  a  short,  informative  summary 
of  the  vessel  particulars.  The  documentation  of  the  vessel’s  structural  history  is  very  helpful. 
Especially  the  illustrations  of  the  structural  details  with  high  stress  concentrations  indicating  the 
possible  crack  locations  are  valuable  information. 

The  complete  lack  of  information  with  regard  to  the  critical  inspection  areas  constitutes  a 
significant  flaw  in  the  CAIP  report  for  the  Vessel  C. 

The  inclusion  of  actual  survey  reports  as  appendices  increases  the  volume  of  the  report  and 
is  detrimental  to  the  stated  objective  of  Critical  Area  Inspection  Plans  to  be  used  as  a  concise 
summary  of  the  vessel’s  history  and  present  status  with  respect  to  structural  failures. 


5.4.4  Vessel  D 

5. 4.4.1  Description 

The  Critical  Area  Inspection  Plan  report  for  the  Vessel  D  contains  a  short  description  of  the  main 
vessel  particulars.  A  top  view  of  the  vessel  shows  the  location  of  all  tanks.  A  short  description  of 
the  vessel’s  travel  history  is  included. 

As  part  of  the  description  of  the  vessel’s  structural  history,  plans  are  provided  that  indicate 
areas  of  high  stress  concentrations  that  are  most  likely  to  show  fatigue  failures. 

The  summary  of  the  fracture  history  contains  graphical  output  from  ARCO’s  proprietary 
fracture  database  showing  the  longitudinal  and  transverse  distribution  of  fractures  for  different 
inspections.  A  detailed  description  of  the  Hull  Fracture  Database  (HFDB)  is  included. 

The  results  of  a  study  titled  Structural  Fatigue  Damage  Assessment  of  ARCO  120,000  dead¬ 
weight  Tankers  are  documented  including  illustrations  of  finite  element  models  for  several  local 
models. 

The  fracture  history  is  documented  showing  the  original  and  the  modified  design  for  the  three 
most  frequent  fractures.  Based  on  the  database  analysis  it  is  concluded  that  the  number  of  fractures 
for  these  details  has  decreased. 

A  summary  of  fractures  categorized  according  to  severity  and  structural  member  shows  that 
most  fractures  occur  in  longitudinals.  A  graphical  summary  of  the  longitudinal  and  transverse 
distribution  of  fractures  found  between  1990  and  1993  is  given.  From  a  pie-chart  representation 
showing  the  percentage  of  fractures  per  severity  category  it  can  be  seen  that  81  %  of  the  fractures 
are  under  12  inches  in  length. 

The  tank  coating  history  is  documented.  For  each  tank  the  tank  protection  system,  the  coating 
condition,  the  last  inspection  date  and  the  last  renewal  date  are  listed. 

The  external  surveys  that  have  taken  place  since  the  CAIP  requirement  for  the  Vessel  D  was 
issued  are  summarized. 
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Appendix  I  contains  a  sample  of  a  typical  survey  report.  Appendix  II  explains  how  to  record 
fractures  and  contains  the  Fracture  Record  Sheets  that  are  used  to  report  the  fractures  and  to 
update  the  Hull  Fracture  Database.  Additional  appendixes  contain  the  survey  reports  that  have 
taken  place  since  the  plan  was  issued.  In  appendix  III  the  survey  report  of  the  cargo  block 
inspection  performed  in  May  1990  is  included. 

5. 4.4. 2  CAIP  Performance  Elements  Evaluation 

Executive  Summary 

No  executive  summary  is  contained  in  the  Critical  Area  Inspection  Plan  report  for  the  Vessel 
D. 

Vessel  Particulars 

The  location  of  all  tanks  is  shown  in  a  top  view.  In  addition,  the  following  vessel  particulars 
are  listed: 

•  Builder 

•  Delivery  Date 

•  Hull  No. 

•  Class 

•  LOA 

•  LBP 

•  SLL 

•  Beam,  molded,  MS 

•  Depth,  molded 

•  Summer  DWT 


Historical  Information 

A  short  summary  of  the  vessel  history  is  provided  indicating  that  no  major  structural  modifi¬ 
cations  have  been  made  to  the  vessel  during  its  sailing  life. 

The  results  of  a  structural  study  to  determine  details  with  high  stress  concentrations  are 
included  as  part  of  the  structural  history.  Illustrations  of  these  details  indicating  the  problem  areas 
are  provided.  These  illustrations  are  very  informative  and  document  possible  crack  locations. 

The  results  of  a  study  titled  Structural  Fatigue  Damage  Assessment  of  ARCO  120,000  dead¬ 
weight  Tankers  are  documented  including  illustrations  of  finite  element  models  for  several  local 
models.  This  study  uses  the  original  vessel  log  entries  to  determine  the  cyclic  loading  for  the  vessel 
during  its  service  life.  Using  these  loads  in  conjunction  with  global  and  local  finite  element  models, 
the  fatigue  life  for  several  critical  detail  locations  is  analysed.  The  results  of  these  analyses  are 
included  in  the  CAIP  report. 

The  fracture  history  is  documented  showing  the  original  and  the  modified  design  for  the  three 
most  frequent  fractures.  Based  on  the  database  analysis  it  is  concluded  that  the  number  of  fractures 
for  these  details  has  decreased. 

As  part  of  the  documentation  of  the  fracture  history,  the  longitudinal  and  transverse  distri¬ 
bution  of  fractures  in  the  hull  is  shown  for  the  different  surveys.  In  addition,  the  main  fractures 
are  described  and  are  shown  in  detail  drawings.  The  repair  method  is  stated.  Examples  of  detail 
modifications  to  reduce  stress  concentrations  are  included. 

In  order  to  summarize  the  fracture  history,  the  failures  are  listed  according  to  the  structural 
member  and  the  severity.  This  information  is  also  presented  graphically. 
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Active  Repair  Areas 

No  active  repair  areas  are  mentioned.  No  information  identifying  problems  in  active  repair 
areas  is  included  in  the  report. 

Structural  Inspections 

A  short  list,  indicating  the  external  surveys  performed  since  the  CAIP  requirement  for  the 
Vessel  D  was  issued,  is  presented  showing  the  survey  date,  the  inspection  method,  the  inspectors 
names  and  remarks  about  the  survey  findings  and  work  performed. 

Tank  Coating  Systems 

The  tank  coating  history  lists  for  each  tank  the  tank  protection,  the  coating  condition  (new, 
good,  fair,  poor),  the  last  inspection  date,  remarks  and  the  last  renewal  date. 

Critical  Areas  Inspection  Plan  Update 

The  CAIP  report  indicates  the  intention  to  provide  updates  of  the  fracture  history  after  the 
biennial  shipyard  overhaul.  In  addition,  a  complete  report  of  the  fractures  detected,  along  with 
repairs  and/or  structural  modifications  will  be  incorporated  in  an  appendix  to  the  CAIP. 

5.4.4. 3  Summary 

The  Critical  Area  Inspection  Plan  report  for  the  Vessel  D  contains  a  short,  informative  summary 
of  the  vessel  particulars.  The  documentation  of  the  vessel’s  structural  history  is  very  helpful. 
Especially  the  illustrations  of  the  structural  details  with  high  stress  concentrations  indicating  the 
possible  crack  locations  are  valuable  information. 

The  reference  to  the  fatigue  life  evaluation  study  is  helpful,  although  the  documentation  is  too 
extensive  for  the  purpose  of  the  Critical  Area  Inspection  Plan  report. 

The  complete  lack  of  information  with  regard  to  the  critical  inspection  areas  constitutes  a 
significant  flaw  in  the  CAIP  report  for  the  Vessel  D. 

The  inclusion  of  actual  survey  reports  as  appendices  increases  the  volume  of  the  report  and 
is  detrimental  to  the  stated  objective  of  Critical  Area  Inspection  Plans  to  be  used  as  a  concise 
summary  of  the  vessel’s  history  and  present  status  with  respect  to  structural  failures. 

5.4.5  Vessel  E 
5. 4. 5.1  Description 

The  Critical  Area  Inspection  Plan  for  the  Vessel  E  follows  the  NVIC  format  very  closely.  The 
vessel  particulars  are  listed  including  a  general  arrangement  drawing,  a  list  of  tanks,  a  machinery 
description  and  international  load  lines. 

A  summary  of  past  structural  failures  is  given.  For  Class  1,  Class  2  and  pattern  type  Class  3 
failures,  the  fracture  locations,  repair  information  is  listed  indicating  repair  success  where  applica¬ 
ble. 

A  table  of  structural  failures  is  listed,  documenting  tank,  the  tank  type,  the  location  the  failure 
type,  the  repair/modification,  the  survey  date,  the  failure  class  and  comments  for  each  failure. 
Reference  is  made  to  the  individual  inspection  reports  for  additional  information.  A  nomenclature 
for  the  keywords  used  in  the  failure  table  is  provided. 

A  list  of  structural  inspections,  including  the  next  scheduled  drydock  survey,  is  given.  Inspec¬ 
tion  reports  and  inspection  companies  are  listed. 

The  tank  coating  system  is  summarized,  describing  the  original  coating  system  and  coating 
repair.  In  addition,  a  coating  maintenance  plan  is  summarized. 
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5.4. 5. 2  CAIP  Performance  Elements  Evaluation 

Executive  Summary 

No  Executive  Summary  included. 


Vessel  Particulars 

General  Arrangement,  tank  description,  Machinery  and  load  lines  are  summarized.  The  list  of 
vessel  particulars  includes  the  following  information; 

•  Name 

•  Hull  No. 

•  Coast  Guard  ID 

•  ABS  ID 

•  Vessel  Class 

•  Builder 

•  Delivery 

•  DWT 

•  Presence  of  SBT 

•  Presence  of  IGS 

•  Presence  of  COW 

•  Presence  of  Heating  Coils 

Historical  Information 

Summary  of  Class  1,  Class  2  and  Class  3  failures.  For  Class  1,  Class  2  and  pattern  type  Class  3 
failures,  a  short  summary  of  the  cracking  problem,  the  repair  solution  and  an  assessment  of  the 
repair  success  is  given.  No  graphical  representation  is  available. 

The  tabular  listing  of  failures  lists  tank  no.,  tank  type,  failure  location,  failure  type,  repair 
method,  survey  date,  failure  class  and  comments.  Due  to  the  lack  of  a  graphical  representation, 
this  information  is  not  very  informative. 

Vessel  structural  modifications  are  listed  separately.  No  drawings  for  detail  modifications  are 
presented.  References  for  structural  surveys  and  structural  analysis  are  included. 

The  coating  systems  summary  contains  a  description  of  the  original  coating  system,  coating 
repairs  and  a  coating  maintenance  plan. 

Active  Repair  Areas 

The  report  states  that  the  Vessel  E  has  no  active  repair  areas. 

Structural  Inspections 

The  documentation  of  structural  inspections  states  the  inspection  schedule  for  drydock  surveys, 
structural  surveys  by  ABS  and  USCG  and  owner’s  inspections.  In  addition  the  date  and  inspection 
company  for  each  inspection  report  are  listed.  No  summary  of  the  inspections  is  presented. 

Tank  Coating  Systems 

The  original  coating  system  is  summarized  and  coating  repairs  are  documented.  A  coating 
maintenance  plan  outlines  the  planned  renewal.  No  summary  of  present  condition  and  coating 
failure  percentage  is  given. 
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Critical  Areas  Inspection  Plan  Update 

The  report  states  that  information  from  1991  periodic  overhaul  and  all  structural  information 
thereafter  will  be  entered  in  CATSIR  database  which  will  form  an  update  for  the  Critical  Area 
Inspection  Plan.  CAIP  will  be  automatically  updated  after  each  inspection  and  repair, 

5. 4. 5. 3  Summary 

The  Critical  Area  Inspection  Plan  for  the  Vessel  E  follows  in  its  structure  very  closely  the  format 
outlined  in  enclosure  2  of  the  Navigation  and  Vessel  Inspection  Circnlar  15-91,  [15].  The  lack  of 
graphical  representations  of  failure  distributions  in  the  vessel  and  the  minimal  documentation  of 
failures  in  active  repair  areas  constitute  a  significant  limit  in  the  usefulness  of  this  CAIP. 

5.4.6  Vessel  F 

5.4. 6.1  Description 

The  Vessel  F  is  a  255,350  dwt  steam  powered  crude  oil  tanker  engaged  in  worldwide  trade.  The 
vessel  is  owned  by  the  Swansea  Corporation  which  is  wholly  owned  subsidiary  of  the  Amerada 
Hess  Corporation. 

The  CAIP  report  for  the  Vessel  F  contains  an  executive  summary  describing  the  vessel  and 
its  trade  route  and  summarizing  the  contents  of  the  CAIP  report  without  presenting  specific 
information. 

A  general  vessel  description  contains  the  main  vessel  particulars,  the  builder  and  the  vessel 
classification.  The  cargo  tank  arrangement  is  described  and  a  capacity  plan  and  a  midship  section 
drawing  are  attached. 

A  detailed  summary  of  the  typical  full  load  and  arrival  ballast  patterns  is  presented  including 
cargo  distribution  and  shear  and  bending  moment  distributions. 

As  part  of  the  historical  information  consists,  particulars  of  the  most  recent  surveys  are  sum¬ 
marized.  During  these  surveys  only  cracks  in  welds  and  brackets  have  been  found.  Due  to  the  small 
number  of  cracks  found,  no  major  structural  modifications  have  been  necessary.  The  CAIP  report 
summarizes  the  structural  repairs  in  a  very  detailed  fashion  and  provides  sketches  of  these  repairs. 
Modifications  of  structural  details  are  summarized  extensively  using  lists  of  modified  details  and 
detail  drawings. 

The  tank  protection  systems  of  the  Vessel  F  are  described.  The  installation  of  anode  systems 
in  areas  where  increased  corrosion  rates  have  been  experienced  is  summarized. 

A  very  detailed  set  of  guidelines  for  tank  inspections  is  included  in  the  CAIP  report.  These 
guidelines  include  rafting  guidelines,  safety  requirements,  information  about  orientation  in  tanks 
and  sample  tank  information  sheets. 

Copies  of  the  survey  reports  of  the  most  recent  structural  surveys  have  been  submitted  as  an 
addendum  to  this  CAIP  report. 

5.4. 6. 2  CAIP  Performance  Elements  Evaluation 
Executive  Summary 

The  executive  summary  identifies  the  vessel  owner  and  the  main  trade  route.  In  addition,  the 
summary  states  the  purpose  of  the  CAIP  report.  No  details  about  critical  inspection  areas  or 
specific  failures  are  provided. 

Vessel  Particulars 

The  vessel  history  (builder,  delivery,  original  owner,  classification  society)  is  stated.  The 
following  vessel  information  is  listed: 

•  Length  Overall 
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•  Length  Between  PP 

•  Breadth  Molded 

•  Depth  Molded 

•  Draft 

•  SDWT 

•  LTWT 

•  Installed  Power 

The  cargo  tank  arrangement  is  described  and  documented  with  a  copy  of  the  Capacity  Plan. 
In  addition,  a  midship  section  drawing  is  provided.  Information  about  the  crude  oil  washing  and 
inert  gas  systems  is  included. 

Typical  full  load  and  arrival  ballast  patterns  are  summarized.  For  each  load  case  the  cargo 
distribution  and  shear  and  bending  moment  characteristics  are  shown. 

Historical  Information 

A  short  summary  of  the  past  structural  performance  is  provided.  Structural  repairs  are  doc¬ 
umented  in  detail,  including  size  and  locations  for  additional  brackets,  repair  sketches  and  steel 
renewal  information. 

Modifications  were  developed  in  areas  where  previous  repairs  (re-welding  or  replacement)  have 
been  unsuccessful.  These  modifications  are  documented  using  sketches,  descriptions  of  the  repair 
locations  and  detailed  summaries  of  the  modification  process. 

Active  Repair  Areas 

No  active  repair  areas  are  mentioned  in  the  CAIP  report  for  the  Vessel  F. 

Structural  Inspections 

Information  about  structural  inspections  has  been  provided  as  part  of  the  historical  informa¬ 
tion.  For  the  four  most  recent  surveys,  the  following  information  is  listed: 

•  Inspection  Date 

•  Inspection  Company 

•  Inspector 

•  Instrument 

•  Transducer 

Detailed  guidelines  for  tank  inspections  are  included  in  the  report.  The  guidelines  include 
rafting  guidelines,  safety  regulations,  tank  orientation  requirements  and  tank  inspection  sheets. 

Tank  Coating  Systems 

The  original  anode  system  and  an  additionally  installed  bottom  founded  anode  system  are 
described  in  the  CAIP.  Coating  materials  used  in  the  most  recent  docking  period  are  listed.  Coating 
procedures  and  specific  coating  locations  are  documented. 

Critical  Areas  Inspection  Plan  Update 

No  specific  provisions  for  an  update  of  the  Critical  Area  Inspection  Plan  are  given. 
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5.4. 6. 3  Summary 

The  CAIP  report  for  the  Vessel  F  contains  most  of  the  elements  listed  in  the  format  outlined  in 
enclosure  2  of  the  Navigation  and  Vessel  Inspection  Circular  15-91,  [15].  The  lack  of  graphical 
representations  of  failure  distributions  in  the  vessel  and  the  missing  documentation  of  failures  m 
active  repair  areas  constitute  a  significant  limit  in  the  usefulness  of  this  CAIP. 

The  use  of  actual  survey  reports  as  an  addendum  to  the  CAIP  report  increases  the  volume 
of  the  CAIP  report  and  is  contrary  to  the  stated  objective  of  Critical  Area  Inspection  Plans  as 
a  short,  informative  summary  of  the  general  vessel  status  and  of  the  status  of  critical  inspection 

areas. 

5.4.7  Conclusions  based  on  CAIP  Report  Evaluation 

Six  Critical  Area  Inspection  Plan  reports  from  four  different  operators  have  been  analysed.  This 
analysis  was  intended  to  ; 

•  determine  the  information  content  of  the  CAIP  reports. 

•  evaluate  the  adherence  of  the  reports  to  the  list  of  performance  elements  stated  in  enclosure  2 
of  the  Navigation  and  Vessel  Inspection  Circular  15-91,  [15]. 

•  conclude  on  the  effectiveness  of  the  CAIP  reports  to  achieve  the  goals  that  have  led  to  the 
implementation  of  the  Critical  Area  Inspection  Plan  requirement,  as  stated  in  the  Navigation 
and  Vessel  Inspection  Circular  15-91,  [15]. 

As  stated  in  the  NVIC  15-91,  [15],  a  CAIP  report  is  a  management  tool  that  serves  to  track 
the  historical  performance  of  a  vessel,  identify  problem  areas,  and  provide  greater  focus  to  periodic 
structural  examinations.  . . . 

...The  ultimate  goal  of  a  CAIP  is  to  address  the  cause  of  problems,  not  merely  fAe  symptoms. . . 

Within  the  CAIP  the  surveyor,  inspector,  or  vessel  crew  will  be  able  to  find  detailed  information 
on  the  vessel’s  fracture  history,  corrosion  control  systems,  and  previous  repairs.  The  CAIP  will 
also  contain  a  record  and  evaluation  of  repairs  to  the  vessel  s  fractures.  ^ 

...  The  evaluation  of  permanent  repairs  and/or  design  modifications  is  important  to  the  vessels 

overall  fitness.  . 

These  excerpts  from  NVIC  15-91  summarize  the  underlying  goals  that  have  led  to  the  imple¬ 
mentation  of  the  CAIP  requirement.  It  has  to  be  evaluated  whether  the  existing  CAIP  reports 
meet  these  goals. 

5.4. 7.1  Information  Contents 

Several  of  the  CAIP  reports  do  not  include  an  executive  summary.  In  other  cases,  the  executive 
summaries  do  not  list  the  designated  critical  inspection  areas. 

Large  discrepancies  are  found  between  the  different  CAIP  reports.  All  reports  focus  on  the 
illustration  of  the  vessel’s  failure  history.  However,  only  the  ARCO  reports  illustrate  general  trends 
with  the  help  of  graphical  illustrations  of  the  failure  distributions.  In  all  cases,  the  documentation 
of  detail  failures  does  not  provide  sufficient  information  about  the  cause  of  the  failure  and  the  type 
and  effectiveness  of  repairs. 

The  documentation  of  the  active  repair  areas,  one  of  the  main  goals  of  the  CAIP  requirement,  is 
not  implemented  by  the  majority  of  the  CAIP  reports.  The  CAIP  reports  for  the  two  CHEVRON 
vessels  list  the  critical  repair  areas,  but  fail  to  include  detailed  failure  and  repair  information. 

In  most  cases,  the  summary  of  structural  inspections  is  limited  to  the  inspection  date,  in¬ 
spection  company  and  location.  Some  CAIP  reports  include  the  actual  inspection  reports  as  an 
addendum,  which  significantly  increases  the  volume  of  the  CAIP  report. 

The  documentation  of  the  tank  coating  systems  has  been  included  with  sufficient  detail.  The 
representation  of  the  coating  systems  separately  for  each  tank  conveys  the  information  in  the  most 
convenient  way. 
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5.4.7. 2  Adherence  to  Performance  Elements  of  NVIC  15-91 

All  reviewed  CAIP  reports  follow  in  general  the  list  of  performance  elements  outlined  in  enclosure  2 
of  NVIC  15-91,  [15].  The  majority  of  the  CAIP  reports  do  not  provide  sufficient  information  with 
respect  to  the  critical  repair  areas,  one  of  the  main  concerns  of  the  Critical  Area  Inspection  Plan 
requirement.  The  description  of  trends  and  causes  for  failures  is  also  not  addressed  adequately. 

5.4. 7. 3  Effectiveness  of  CAIP  Reports 

Based  on  the  information  contents  and  the  representation  style  of  the  six  CAIP  reports  that  have 
been  reviewed,  it  has  to  be  concluded  that  none  of  the  reports  completely  satisfies  the  goals  and 
purpose  that  are  inherent  in  the  Critical  Area  Inspection  Plan  requirement. 

The  lack  of  graphical  representations  of  failure  trends  makes  it  difficult  to  anticipate  po.ssible 
critical  areas.  Finding  trends  in  the  failure  data  is  also  an  important  method  to  determine  causes 
for  failures.  The  lack  of  trend  information  is  therefore  detrimental  to  the  goals  of  the  CAIP 
requirement. 

In  general,  most  CAIP  reports  include  additional  information  (survey  reports,  sample  inspec¬ 
tion  sheets,  surveying  guidelines,  etc.).  This  additional  information  reduces  the  effectiveness  of  the 
CAIP  reports  due  to  the  increased  volume  of  the  report.  CAIP  reports  are  intended  to  be  short 
and  concise  summaries  of  a  vessel’s  failure  history  with  special  emphasis  to  critical  repair  areas 
and  the  effectiveness  of  permanent  repairs  and  modifications. 


5.5  Experience  of  U.S.  Coast  Guard  Inspectors 

As  stated  in  NVIC  15-91,  [15],  Critical  Area  Inspection  Plans  are  intended  to  help  inspectors  to 
gain  familiarity  with  a  vessel,  the  past  failure  history  and  critical  areas. 

Discussions  with  U.S.  Coast  Guard  Traveling  Inspectors  have  been  held  to  obtain  their  im¬ 
pression  about  the  effectiveness  of  the  CAIP  requirement  and  to  define  an  improved  CAIP  report 
format. 

Overall,  the  implementation  of  the  CAIP  requirement  has  led  to  a  reduction  in  fractures. 
Owner  participation  has  improved  and  more  detailed  analyses  are  performed  to  determine  causes 
for  fractures. 

In  general,  the  CAIP  reports  are  perceived  as  being  informative  and  helpful  to  learn  about  a 
particular  vessel.  However,  some  reports  contain  too  much  information  that  makes  you  not  want 
to  read  the  report.  In  particular,  the  inclusion  of  complete  survey  reports  is  seen  as  detrimental  to 
the  purpose  of  the  CAIP  requirement. 

According  to  U.S.  Coast  Guard  Traveling  Inspectors,  present  CAIP  reports  could  be  improved 
by  including  the  following  information: 

•  Overview  drawings  of  the  tank  structure  indicating  the  critical  inspection  areas 

•  Representative  sketches  of  fractures  in  critical  inspection  areas 

As  an  example  of  the  effectiveness  of  the  CAIP  requirement,  the  Atigun  Pass  class  is  mentioned. 
In  previous  inspections,  hundreds  of  fractures  were  found  in  one  inspection  period,  mainly  fractures 
of  the  sideshell  longitudinal  to  webframe  connection.  During  the  last  inspection  of  the  Exxon 
Benicia,  no  sideshell  longitudinal  fractures  were  observed. 


5.6  SCAQMD  Emission  of  Volatile  Organic  Compounds 
Reporting  Requirement 

As  one  example  of  reporting  requirement  for  component  failures,  the  reporting  requirement  for  Rule 
1173  violations  established  by  the  South  Coast  Air  Quality  Management  District  (SCAQMD)  is 
described.  Although  not  closely  related  to  structural  failures  of  tanker  details,  the  reporting 
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requirements  nevertheless  identify  the  stringent  definition  requirements  for  electronic  transmission 
of  data. 

5.6.1  Overview 

The  South  Coast  Air  Quality  Management  District  has  developed  the  nation’s  most  advanced  air 
pollution  program  to  reduce  air  pollution  in  Los  Angeles,  Orange, Riverside  and  the  non-desert 
portion  of  San  Bernardino  Counties.  The  District  regulations  are  aimed  at  reducing  Volatile 
Organic  Compounds  (VOC)  and  other  emissions  which  contribute  to  air  pollution. 

In  [10]  the  District  Rule  1173  about  Fugitive  Emissions  of  Volatile  Organic  Compounds 
is  documented  and  described.  Rule  1173  is  aimed  at  reducing  VOC  emissions  by  requiring  the 
timely  repair  of  leaking  components.  In  order  to  achieve  compliance  with  rule  1173,  the  SCAQMD 
has  outlined  a  four  part  process: 

•  Identification  -  All  components  in  VOC  service  have  to  be  identified.  A  differentiation  is 
made  between  major  and  minor  components. 

•  Inspection  -  Rule  1173  requires  that  VOC  components  are  inspected  quarterly  or  annually 
depending  on  the  accessability  of  the  component  and  the  overall  history  of  leaks  at  the 
facility. 

•  Repairs  -  A  timetable  is  provided  in  Rule  1173  which  indicates  the  amount  of  time  is  alloted 
to  operators  to  repair  a  particular  type  of  leak.  Components  which  are  repaired  five  times  in 
one  twelve-month  period  must  be  replaced  with  Best  Available  Control  Technology  (BACT) 
or  Best  Available  Retrofit  Technology  (BART). 

•  Reports  and  Recordkeeping  -  Records  of  leaks  detected  during  quarterly  inspections,  and 
subsequent  repairs  and  reinspections  are  to  be  submitted  to  the  SCAQMD  in  a  quarterly 
report  following  the  leak,  repair  or  reinspection.  Reports  can  be  submitted  on  a  floppy  disk. 

5.6.2  Reporting  Format 

With  the  adoption  of  Rule  1173,  the  District  has  initiated  a  computer  reporting  procedure.  Infor¬ 
mation  submitted  to  the  District  on  a  floppy  disk  can  be  downloaded  to  the  SCAQMD  computer 
system. 

Each  company  has  to  prepare  a  component  summary  sheet  listing  the  component  type,  inspec¬ 
tion  period  and  no.  of  components  identified.  The  component  summary  sheet  has  to  be  kept  on 
site  and  has  to  be  made  available  to  the  SCAQMD  upon  request. 

For  each  component  type  a  component  identification  plan  has  to  be  prepared  that  lists  for  each 
component  the  service  type,  the  location  and  the  accessability.  The  component  idenfication  plan 
has  to  be  kept  on  site  and  has  to  be  made  available  to  the  SCAQMD  upon  request. 

The  statistics  summary  sheet  is  a  quarterly  report  that  lists  for  each  component  type  the  total 
number  of  components  inspected,  the  total  number  of  liquid  leaks,  the  total  number  of  gas  leaks 
in  three  severity  categories,  the  number  of  replaced  or  retrofitted  components  and  the  number  of 
inaccessible  components.  The  statistics  summary  sheet  can  be  submitted  electronically.  The  data 
file  contains  one  header  line  and  six  (6)  data  lines,  one  line  for  each  component  type  (VALVES, 
FITTINGS,  PUMPS,  COMRESSORS,  PRDS,  OTHERS).  Each  data  file  will  be  submitted  as  an 
industry  standard  ASCII  comma  and  quote  delimited  file  on  a  standard  720  Kb  MS-DOS  or  PC- 
DOS  formatted  disk.  The  file  format  is  defined  as  follows: 
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Column  Name 

Type 

Length 

Expression 

AEISID 

Integer 

8 

SCAQMD  identification  number 

QTR 

Integer 

1 

Reporting  quarter 

YR 

Integer 

4 

Reporting  year 

COMPNAME 

Text 

40 

Name  of  reporting  company 

ADDRESS 

Text 

40 

Address  of  facility 

CONTACT 

Text 

40 

Name  of  contact  person 

PHONE 

Text 

12 

Phone  number  of  contact 

TYPE 

Text 

10 

Type  of  Component 

TOTAL 

Integer 

8 

Total  inspected  for  component  type 

TOTLL 

Integer 

8 

Total  number  of  components  with  liquid  leaks 

LEAK210K 

Integer 

8 

Comp,  with  leak  rate  >  l,000ppm 

LEAK250K 

Integer 

8 

Comp,  with  leak  rate  >  10,000ppm 

LEAKGT50 

Integer 

8 

Comp,  with  leak  rate  >  50,000ppm 

REPAIR 

Integer 

8 

Replaced  components  (BACT/BART) 

ANNUAL 

Integer 

8 

inaccessible  comp. 

The  quarterly/annual  component  leak  report  documents  the  individual  leak  incidents  for  each 
component  type.  The  header  line  is  followed  by  one  data  line  for  each  leaking  component.  The 
leaking  components  will  be  grouped  and  listed  by  component  type,  i.e.  Valves,  Fittings,  Others, 
Pumps,  Compressors,  and  PRDs.  Each  data  file  will  be  submitted  as  an  industry  standard  ASCII 
comma  and  quote  delimited  file  on  a  standard  720  Kb  MS-DOS  or  PC-DOS  formatted  disk.  The 
file  format  is  defined  as  follows: 


Column  Name 

Type 

Length 

Expression 

AEISID 

Integer 

8 

SCAQMD  identification  number 

QTR 

Integer 

1 

Reporting  quarter 

YR 

Integer 

4 

Reporting  year 

COMPNAME 

Text 

40 

Name  of  reporting  company 

ADDRESS 

Text 

40 

Address  of  facility 

CONTACT 

Text 

40 

Name  of  contact  person 

PHONE 

Text 

12 

Phone  number  of  contact 

TYPE 

Text 

10 

Type  of  Component 

COMPTID 

Text 

10 

Unique  ID  number 

SERVICE 

Text 

4 

Type  of  service  (liquid,  gas,  both) 

LOCATION 

Text 

10 

Physical  location  of  component 

INSPDATE 

Date 

8 

Date  inspection  was  conducted 

LEAKRATE 

Integer 

8 

Leak  rate  measurement  in  ppm 

LIQUID 

Text 

1 

Was  this  a  liquid  leak  ? 

REPTYPE 

Text 

25 

Type  of  repair 

REPDATE 

Date 

8 

Date  of  repair  (mm/dd/yy) 

POSTRATE 

Integer 

8 

Post  repair  leak  rate  measurement  in  ppm 

5.6.3  Summary 

The  documentation  of  component  leaks  that  cause  fugitive  emissions  of  volatile  organic  compounds 
(VOC)  is  defined  in  [10].  A  fixed  format  is  provided  to  summarize  and  identify  all  components  and 
to  document  all  leaks  detected  during  inspections.  The  documentation  of  components  leaks  can 
be  submitted  electronically  following  a  clearly  defined  database  format.  It  is  the  benefit  of  this 
procedure  that  all  leaks  can  be  readily  entered  into  the  SCAQMD  database. 
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5.7  Improved  CAIP  Format  Recommendation 

Based  on  the  evaluation  of  existing  CAIP  reports,  a  recommendation  for  an  improved  format  is 
made.  This  format  will  follow  the  list  of  performance  elements  outlined  in  enclosure  2  of  the 

Navigation  and  Vessel  Inspection  Circular  15-91  (NVIC  15-91),  [15]. 

This  list  contains  all  the  information  elements  that  are  important  to  ensure  the  efficiency  of  a 
CAIP  report.  In  the  following,  the  recommended  information  contents  for  each  of  the  CAIP  report 
elements  is  listed. 

5.7.1  Executive  Summary 

The  executive  summary  is  intended  to  provide  general  information  and  summarize  the  vessel  status. 
The  following  information  has  to  be  provided: 

•  Vessel  name,  construction  type,  date  built,  shipyard,  original  and  subsequent  owners,  mam 
trade  route 

•  contents  of  CAIP  report 

•  list  of  designated  critical  inspection  areas 

5.7.2  Vessel  Particulars 

The  summary  of  vessel  particulars  is  intended  to  provide  a  concise  summary  of  the  main  vessel 
characteristics.  This  information  has  to  give  the  surveyor  or  inspector  sufficient  information  about 
the  vessel  and  the  tank  locations.  The  following  information  has  to  be  provided: 

•  Name,  Official  Number,  design  class,  builder,  delivery  date,  cargo  type,  classification 

•  LOA,  LPP,  breadth  molded,  depth  molded,  draft,  SDWT,  LTWT 

•  general  arrangement  plan  indicating  the  tank  locations 

•  list  of  tanks  including  name,  tank  type,  capacity 

5.7.3  Historical  Information 

Information  with  regard  to  structural  failures  and  vessel  structural  modifications  has  to  be  pro¬ 
vided.  This  information  is  intended  to  identify  failures  that  have  been  successfully  repaired  with 
no  recurrence.  It  is  important  to  provide  this  information  in  a  structured  form  that  identifies  the 
type  of  failure  using  illustrations  wherever  possible,  the  failure  location  and  the  repair  method. 
The  following  information  has  to  be  provided  to  document  structural  failures. 

•  Total  number  of  failures  per  failure  class 

•  Longitudinal  distribution  of  failures 

•  Transverse  distribution  of  failures 

•  Information  about  main  failures  (ordered  by  number  of  occurrences) 

-  description 

-  location 

-  illustration 

-  cause  (if  known) 

-  repair 

-  effectiveness  of  repair 
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Structural  modifications  have  to  be  documented  identifying  major  modifications  and  detail 
modifications 

•  list  of  major  structural  modifications 

—  location 

—  description 

—  illustration 

—  cause 

•  detail  modifications 

—  location 

—  description 

—  illustration 

—  cause 

5.7.4  Active  Repair  Areas 

The  documentation  of  structural  failures  in  active  repair  areas  has  to  be  more  detailed  than  for 
other  areas  of  the  vessel.  The  following  information  has  to  be  provided  for  each  critical  repair  area: 

•  Information  about  specific  failures  (ordered  by  number  of  occurrences) 

—  description 

—  location 

—  illustration 

—  cause  (if  known) 

—  repair 

—  effectiveness  of  repair 

•  vessel  structural  modifications 

—  major  structural  modifications 

—  detail  modifications 

•  structural  analyses 

—  reason  for  analysis 

—  result  summary 

—  reference 

•  trends 

—  description 

—  graphical  representation 

—  causes 
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5.7.5  Structural  Inspections 

The  documentation  of  the  structural  inspections  is  intended  to  provide  a  record  of  the  vessel’s 
inspection  history.  The  following  information  can  be  presented  in  a  concise,  tabular  form: 

•  Critical  Area  Inspection  Intervals 

•  Internal  inspections 

-  tank 

-  date 

—  method 

-  inspected  by 

—  inspector(s) 

—  problems  noted 

•  External  surveys 

-  date 

-  inspection  method 

—  inspected  by 

—  problems  noted 

5.7.6  Tank  Coating  Systems 

The  section  describing  the  vessel’s  tank  coating  system  has  to  provide  sufficient  information  about 
the  original  coating  system,  coating  failures,  coating  repairs,  planned  renewals  and  the  present 
coating  condition.  This  information  can  be  listed  for  each  tank  in  a  tabular  form  stating. 

•  original  coating  system 

•  coating  renewal  (date,  type,  cause) 

•  planned  renewal 

•  present  condition 

5.7.7  CAIP  Update 

The  final  section  of  the  Critical  Area  Inspection  Plan  indicates  the  plans  for  the  CAIP  update, 
including  the  frequency  of  the  internal  company  reviews. 
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Figure  5.1:  Documentation  of  Structural  Failures 
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Chapter  6 

Database  Structure  for  SSIIS 


6.1  Introduction 

In  chapter  2  the  need  for  a  general  vessel  information  system  has  been  documented.  The  large 
amounts  of  information  that  have  to  be  stored  and  processed  as  the  result  of  vessel  operations 
make  the  need  for  a  vessel  database  even  more  pronounced. 

Several  database  systems  have  been  developed  to  address  some  of  the  data  management  needs. 
These  systems  have  been  described  and  analysed  in  chapter  3  in  order  to  determine  important 
features  and  operational  experiences. 

In  order  to  determine  the  information  contents  of  an  integrated  vessel  database  system,  several 
analysis  software  applications  have  been  studied.  The  information  need  of  each  system  has  been 
summarized  in  chapter  4. 

One  of  the  requirements  for  the  SSIIS  database  system  is  the  ability  to  produce  Critical  Area 
Inspection  Plan  (CAIP)  reports  as  required  by  the  U.S.  Coast  Guard.  After  analysing  existing 
CAIP  reports  and  comparing  them  to  the  U.S.  Coast  Guard  requirements  as  stated  in  [15],  an 
improved  CAIP  reporting  format  heis  been  developed  that  will  be  used  to  define  the  CAIP  report 
format  used  by  the  SSIIS  database  system.  This  development  is  documented  in  chapter  5. 

In  the  following  chapter,  the  development  of  an  integrated  database  structure  for  the  Ship 
Structural  Integrity  Information  System  (SSIIS)  is  documented.  In  this  development,  the  evalua¬ 
tion  of  existing  database  system  in  conjunction  with  the  recognized  information  needs  of  the  major 
analysis  applications  is  used  to  define  the  overall,  modular  structure  of  the  database  system. 

For  each  identified  module,  the  general  purpose  and  the  anticipated  information  content  is 
summarized.  In  order  to  create  a  prototype  application  that  can  be  used  to  produce  CAIP  reports, 
a  more  detailed  data  structure  is  developed  for  the  modules  that  contain  information  necessary  for 
the  development  of  CAIP  reports.  This  includes  the  Design,  the  Construction,  the  Inspection 
and  the  Repair  modules. 

Within  these  modules,  the  data  structure  for  the  components  relevant  for  the  generation  of 
CAIP  reports  is  modelled  with  sufficient  detail  to  be  used  for  the  development  and  implementation 
of  the  SSIIS  prototype  application.  This  prototype  development  is  documented  in  chapter  7 


6.2  General  Structure 

The  evaluation  of  existing  database  systems  has  shown  that,  in  order  to  create  a  versatile  appli¬ 
cation,  it  is  necessary  to  clearly  separate  the  database  structure  from  the  database  management 
system.  The  SSIIS  project  has  to  main  objectives  with  regard  to  the  development  of  a  general 
database  system: 

•  Overall  datastructure  for  vessel  database 


84 


•  Database  management  prototype  with  CAIP  reporting  capabilities 

A  database  system  that  is  to  be  used  by  vessel  operators,  classification  societies,  regulatory 
agencies  and  engineering  consultants,  has  to  be  clearly  structured  to  allow  for  a  modular  structure 
of  different  database  uses. 

Fig.  (6.1)  shows  the  overall  structure  of  the  SSIIS  database  system.  The  core  of  the  system  is  the 
Vessel  Database  which  contains  eight  different  information  modules.  The  different  modules  can 
be  grouped  into  the  three  areas  of  vessel  configuration,  vessel  maintenance  and  vessel  operations. 

In  order  to  manipulate  the  information  contained  in  the  Vessel  Database,  a  Database  Man¬ 
agement  System,  (DBMS)  is  needed.  This  system  has  the  three  main  purposes  Administration, 
Data  Manipulation,  and  Data  Analysis. 

This  dual  structure  makes  it  possible  to  develop  a  modular  database  structure  that  is  intended 
to  contain  all  vessel  relevant  data,  while  the  database  management  system  can  be  custom  tailored 
to  suit  specific  needs  of  operators  or  regulatory  agencies.  The  following  sections  document  the 
development  of  both,  the  Vessel  Database  and  the  Database  Management  system. 

6.3  Vessel  Database  Structure  for  SSIIS 

6.3.1  Module  Summary 

The  core  of  the  database  development  for  the  Ship  Structural  Integrity  Information  System  (SSIIS) 
consists  of  the  design  of  the  overall  database  structure.  The  data  has  to  be  organized  into  modules 
in  order  to  permit  a  step-by-step  development  and  implementation. 

The  modular  concept  makes  it  also  easier  to  comprehend  the  large  amount  of  information  that 
has  to  be  included  in  the  SSIIS  database  structure.  Eight  diiferent  modules  are  used  to  contain 
the  various  vessel  related  information.  Fig.  (6.2)  shows  the  different  modules.  The  following  eight 
modules  are  included  in  the  SSIIS  database  structure: 

•  Design:  This  module  contains  all  general  vessel  information  grouped  in  vessel  classes.  For 
each  class  the  hull  form  and  the  tank  layout  is  included. 

•  Construction:  Structural  drawings  for  each  vessel  class  are  included  in  this  module.  In 
addition,  frame  locations  are  listed  and  a  non-graphical  definition  of  detail  geometries  is 
included. 

•  Modifications:  Structural  modifications,  such  as  hull  extensions,  changes  in  the  tank  ar¬ 
rangement  and  general  design  changes  in  structural  details  are  documented. 

•  Inspection:  The  type  of  inspection,  the  inspection  company  and  the  inspection  date  are 
listed.  Inspection  results  of  both  structural  inspections  and  corrosion  surveys  are  included. 

•  Maintenance:  Coating  renewals,  anode  replacements  and  general  engine  maintenance  are 
listed. 

•  Repair:  Documentation  of  crack  repairs  and  steel  renewals  is  documented  in  this  module. 

•  Operations:  All  operations  related  information  is  included  in  this  module.  This  includes 
detailed  cargo  data  for  all  tanks,  route  information,  weather  data,  crew  list,  engine  log  and 
noon  positions. 

•  Monitoring:  Vessel  response  data  obtained  through  on-board  measurements  is  stored  in 
this  module 

In  the  following  sections,  the  information  contents  for  the  different  modules  is  documented. 
For  the  modules,  that  are  necessary  for  the  development  of  the  prototype  applications,  the  data 
structure  is  defined  in  more  detail.  However,  the  datastructure  for  the  prototype  application  is 
documented  in  chapter  7. 
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Relations  that  are  simply  linked  to  another  relation  represent  one-to-many  relationships.  If 
two  relations  are  linked  through  a  third  relation,  where  the  name  of  the  third  relation  consists  of 
the  names  of  the  two  other  connections,  this  connection  represents  a  many-to-many  relationship. 

Relations  that  are  printed  in  grey  are  relations  that  are  contained  in  a  different  module.  These 
relations  therefore  document  the  connections  between  the  different  modules. 

For  each  module,  the  general  purpose  of  the  module  is  described.  Each  relation  within  the 
module  is  listed  stating  the  purpose  and  the  main  data  contents  in  the  module. 

6.3.2  Design  Module 

6. 3. 2.1  Purpose 

The  Design  module  contains  all  the  general  vessel  information.  It  is  intended  to  be  complete  for 
all  the  information  that  is  not  operations  dependent  and  that  represents  the  initial,  as-built  state 
of  each  vessel.  Fig.  (6.3)  shows  the  data  structure  of  the  Design  module. 

The  information  is  subdivided  into  Ship  and  Class  related  information.  This  closely  resembles 
the  real-life  configuration,  where  ships  of  the  same  class  are  of  identical  design  and  construction. 
It  also  minimizes  repetitive  data  input. 

Data  that  can  vary  for  each  voyage  is  contained  in  the  Voyage  module.  Changes  in  the  original 
vessel  configuration  ared  documented  in  the  Modifications  module. 

6. 3. 2. 2  Class  Relation 

The  Class  relation  contains  all  information  with  respect  to  a  class  of  vessels.  This  includes  the  class 
name,  the  vessel  particulars  for  all  vessels  of  a  particular  class.  Construction  related  information 
is  contained  in  the  Construction  module.  Information  with  regard  to  the  hull  form  is  contained 
in  the  Hull  Form  relation.  General  tank  arrangement,  tank  geometry  and  corrosion  protection 
(coating,  anodes)  are  contained  in  the  Tanks,  Coating,  Anodes  and  Tank  Form  relations. 

The  use  of  a  Class  relation  makes  it  very  easy  to  add  sister  ships  to  the  database,  since  all 
class  related  information  does  not  have  to  be  re-entered. 

Vessel  modifications,  global  hull  changes  (elongations),  changes  in  tank  geometry  or  usage  and 
changes  to  structural  details  are  contained  in  the  Modifications  module, 

6. 3. 2. 3  Hull  Form  Relation 

The  Hull  Form  relation  is  linked  to  the  Class  relation.  It  is  intended  to  contain  the  hull  description 
for  each  class  of  vessels.  It  will  in  general  involve  the  offsets  for  a  set  of  design  frames  and  the 
longitudinal  offsets  of  the  design  frames. 

In  addition,  any  appended  volumes  have  to  be  fully  described.  The  format  and  contents  of  the 
different  datafiles  used  by  the  HECSALV  program,  described  in  section  4.1,  shows  the  information 
contents  necessary  for  a  complete  description  of  the  hull  form. 

Information  in  the  Hull  Form  relation  can  mainly  be  used  as  input  information  for  analysis 
software,  but  will  also  be  used  in  conjunction  with  the  information  contained  in  the  Tanks  relation 
to  create  vessel  illustrations  within  the  database  management  system  (i.e.  General  Arrangement 
drawings). 

In  order  to  fully  develop  the  data  structure  and  information  contents  of  the  Hull  Form  re¬ 
lation,  additional  research  is  needed.  This  has  to  include  the  evaluation  of  existing  hull  form 
representation  formats,  the  development  of  efficient  data  structures  and  a  classification  system  for 
the  representation  of  appendages. 

6. 3. 2.4  Tanks  Relation 

The  Tanks  relation  contains  the  overall  information  with  regard  to  the  tank  configuration  for  a 
class  of  vessels.  This  includes  the  general  tank  arrangement,  the  tank  names,  the  tank  types,  the 
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presence  of  heating  coils,  etc.. 

The  Tanks  relation  is  very  important  for  the  complete  representation  of  the  vessel  configura¬ 
tion.  Tanks  are  a  primary  definition  of  the  location  within  a  vessel.  The  different  tank  usages 
are  important  information  for  the  correct  determination  of  corrosion  rates  and  the  reasons  for 
fatigue  failure.  In  addition,  the  location  of  the  different  tanks  has  to  be  known  to  develop  general 
arrangement  plans  based  purely  on  database  information. 

The  tank  usage  information  simply  distinguishes  between  ballast  only,  cargo  /  dirty  ballast,  and 
cargo  tanks.  A  more  complete  description  of  the  cargo  composition  is  contained  in  the  Operations 
module. 

Information  regarding  the  coating  system  used  in  each  tank  is  contained  in  the  Coating  rela¬ 
tion.  The  number  and  type  of  anodes  used  in  ballast  tanks  is  summarized  in  the  Anodes  relation. 
Most  important,  the  tank  form  description  for  each  tank  is  contained  in  the  Tank  Form  relation. 
The  subdivision  of  the  tank  information  into  several  relations  simplifies  the  data  input  and  clarified 
the  overall  data  structure. 

6. 3. 2. 5  Coating  Relation 

The  Coating  relation  contains  information  with  regard  to  the  coating  of  specific  tanks,  in  gen¬ 
eral  only  cargo  tanks.  This  includes  the  coating  material,  the  manufacturer,  the  humidity  and 
temperature  at  the  time  the  coating  was  applied  and  the  coating  thickness. 

For  a  thorough  database  design,  the  material  and  manufacturer  information  should  be  included 
in  an  additional  relation.  This  reduces  input  errors  and  ensures  a  uniform  naming  convention  for 
coating  products. 

Including  the  humidity  and  temperature  makes  it  possible  to  determine  reasons  for  coating 
breakdowns.  Since  the  exposition  to  direct  sunlight  on  the  hull  will  increase  the  temperature,  it 
might  be  desirable  to  include  information  about  possible  heating  effects  due  to  sunlight  in  the 
relation. 

6. 3. 2. 6  Anodes  Relation 

The  Anodes  relation  contains  all  the  information  with  regard  to  the  cathodic  protection  used  in 
different  tanks.  This  includes  the  type  and  number  of  anodes,  the  manufacturer  and  the  type  of 
attachment. 

For  a  thorough  database  design,  the  material  and  manufacturer  information  should  be  included 
in  an  additional  relation.  This  reduces  input  errors  and  ensures  a  uniform  naming  convention  for 
anodes  material  and  manufacturers. 

6. 3. 2. 7  Tank  Form  Relation 

The  Tank  Form  relation  is  linked  to  the  Tanks  relation.  It  is  intended  to  contain  the  tank  descrip¬ 
tion  for  each  tank  of  a  particular  vessel  class.  It  will  in  general  involve  the  offsets  at  both  ends  of  a 
tank  and  the  longitudinal  position  of  the  tank  boundaries.  In  the  case  that  the  tank  shape  changes 
in  longitudinal  direction,  the  offsets  and  longitudinal  position  for  this  change  in  shape  have  also  to 
be  included. 

The  format  and  contents  of  the  different  data  files  used  by  the  HECSALV  program,  described 
in  section  4.1,  shows  the  information  contents  necessary  for  a  complete  description  of  the  tank 
forms. 

Information  in  the  Tank  Form  relation  can  mainly  be  used  as  input  information  for  analysis 
software,  but  will  also  be  used  in  conjunction  with  the  information  contained  in  the  Hull  relation 
to  create  vessel  illustrations  within  the  database  management  system  (i.e.  General  Arrangement 
drawings). 

In  order  to  fully  develop  the  data  structure  and  information  contents  of  the  Tank  Form  relation, 
additional  research  is  needed.  This  has  to  include  the  evaluation  of  existing  tank  form  representa- 
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tion  formats,  the  development  of  efficient  data  structures  and  an  effective  representation  of  tanks 
with  changing  cross-sectional  areas. 

6. 3. 2. 8  Ship  Relation 

The  Ship  relation  contains  the  data  for  individual  vessels.  All  general  vessel  data,  such  as  hull 
shape,  tank  information  and  construction  is  included  in  the  Class  relation  and  the  Construction 
module. 

The  ship  information  consists  largely  of  information  about  the  builder,  the  owner,  the  operator, 
the  classification  society  and  the  type  of  engine.  All  this  information  is  contained  in  additional 
relations.  In  addition,  the  hull  number,  the  U.S.  Coast  Guard  identification  number  and  a  possible 
identification  number  issued  by  the  classification  society  are  included  in  the  Ship  relation. 

Depending  on  owner/operator  experience,  it  might  be  necessary  to  add  additional  information 
to  the  Ship  relation. 

6. 3. 2. 9  Builder  Relation 

The  Builder  relation  contains  the  necessary  information  with  regard  to  the  shipyard,  where  a 
particular  vessel  was  build.  This  relation  is  linked  to  the  Ship  relation,  which  assumes  that  vessels 
of  the  same  class  can  be  built  by  different  shipyards.  If  this  assumption  is  unnessary,  it  is  possible 
to  link  the  Builder  relation  directly  to  the  Class  relation. 

The  Builder  relation  contains  the  name,  address  and  point  of  contact  for  each  shipyard.  The 
use  of  a  separate  relation  for  the  builder  information  reduces  data  entry  errors  and  allows  it  to 
include  expanded  information  about  a  shipyard  with  a  minimal  amount  of  additional  data  entry. 

6.3.2.10  Owner  Relation 

The  Owner  relation  contains  the  name,  address  and  point  of  contact  for  each  vessel  owner.  In 
addition,  the  date,  when  the  vessel  was  bought,  is  included.If  it  is  desired  to  preserve  the  history 
of  the  different  vessel  owners  in  the  lifetime  of  a  vessel,  it  is  necessary  to  modify  the  datastructure 
and  introduce  an  additional  relation  that  links  the  different  owners  to  a  particular  vessel  including 
the  date  of  the  sale  of  the  vessel. 

6.3.2.11  Operator  Relation 

The  Operator  relation  contains  the  name,  address  and  point  of  contact  for  each  vessel  operator. 
In  addition,  the  date,  when  the  company  started  operating  the  vessel,  is  included.  If  it  is  desired 
to  preserve  the  history  of  the  different  vessel  operators  in  the  lifetime  of  a  vessel,  it  is  necessary  to 
modify  the  datastructure  and  introduce  an  additional  relation  that  links  the  different  operators  to 
a  particular  vessel  including  the  date  of  a  change  in  opertors. 

The  use  of  both,  the  Owner  and  the  Operator  relation  makes  it  possible  to  identify  the  cases, 
where  the  vessel  owner  and  the  vessel  operator  are  not  identical. 

6.3.2.12  Classification  Relation 

The  Classification  relation  contains  the  name,  address  and  point  of  contact  for  the  classification 
society  of  each  vessel.  In  addition,  the  type  of  classification  is  also  included. 

The  use  of  a  dedicated  relation  to  contain  the  classfication  society  avoids  possible  misspellings 
and  makes  it  possible  to  include  additional  information  (address,  phone  numbers)  with  a  minimal 
additional  data  input. 
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6.3.2.13  Engine  Relation 

The  Engine  relation  contains  all  the  relevant  engine  related  information.  This  includes  the  engine 
manufacturer,  engine  type,  number  of  cylinders,  the  normal  RPM,  the  number  of  screws,  the 
number  of  blades  per  screw. 

Based  on  the  experience  of  vessel  operators  additional  engine  information  can  be  included  in 
this  relation.  Additional  information  can  be  relevant  in  relation  to  the  daily  engine  log,  that  is 
included  in  the  Operations  module. 

The  engine  manufacturer  information  can  also  be  included  in  a  separate  relation  similar  to 
the  Builder  and  Classification  relations.  This  would  make  it  possible  to  include  more  detailed 
information  (address,  etc.)  into  the  database.  The  same  argument  can  be  used  for  the  engine  type. 

6.3.3  Construction  Module 

6.3.3. 1  Purpose 

The  Construction  module  contains  all  the  information  with  regard  to  the  structural  confiuration 
of  a  vessel  class.  The  module  is  directly  linked  to  the  Class  relation. 

In  this  module,  all  information  with  regard  to  the  general  vessel  construction  is  entered.  This 
can  include  the  complete  set  of  structural  drawings  in  a  computerized  form  such  as  AutoCad^^ 
drawings. 

In  addition,  the  vessel  type  has  to  be  specified.  The  data  format  has  to  be  flexible  enough  to 
incorporate  new  design  types,  e.g.  mid-deck  tankers.  This  requirement  is  realized  through  the  use 
of  a  many-to-many  relationship  that  will  be  explained  in  more  detail  in  the  following  sections. 

Additional  research  will  be  necessary  to  determine  methods  that  make  it  possible  to  positively 
identify  each  structural  component  without  the  use  of  structural  drawings.  This  will  make  it 
possible  to  combine  defect  data  (cracks,  etc.)  with  the  actual  structural  configuration. 

If  a  clearly  structured  representation  of  structural  details  can  be  developed  that  includes  the 
geometric  dimensions  for  all  detail  components,  it  might  be  possible  to  develop  applications  that 
can  automatically  generate  finite  element  models  for  a  structural  detail  at  a  particular  location  in 
the  vessel. 

Fig.  (6.4)  shows  the  data  structure  of  the  Construction  module.  In  addition  to  the  vessel 
type  and  the  structural  drawings,  a  table  of  frame  locations  and  a  table  of  Sideshell  longitudinal 
locations  is  included. 

These  two  tables  can  not  be  considered  to  be  a  final  solution,  since  they  depend  on  (or  imply) 
a  particular  construction  method.  Additional  research  is  needed  to  develop  improved  definitions 
for  the  location  of  structural  details  in  a  vessel. 

6. 3. 3. 2  Vessel  Type  Relation 

The  Vessel  Type  relation  identifies  the  particular  construction  type  of  a  vessel.  It  contains  the 
name  and  the  description  of  each  vessel  construction  method.  In  order  to  have  a  flexible  data 
structure  that  can  be  adapted  easily  to  new  construction  methods,  the  relation  is  built  based  on  the 
concept  that  a  particular  construction  can  consist  of  different  components  (single/  double  bottom 
,  single/double  sides  or  mid-deck).  The  different  components  are  contained  in  the  Component 
relation. 

The  link  between  the  Vessel  Type  and  the  Component  relation  is  provided  with  the  Type  - 
Component  relation.  This  particular  design  thus  realizes  a  many-to-many  relationship. 

6. 3. 3. 3  Type  -  Component  Relation 

The  Type  -  Component  relation  contains  the  different  components  that  comprise  a  particular 
vessel  type.  The  relation  consists  only  of  the  primary  key  of  the  Vessel  Type  relation  and  the 
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primary  key  of  the  Component  relation.  This  makes  it  possible  to  specify  any  number  of  different 
components  for  one  vessel  type  and  also  to  use  one  component  in  more  than  one  vessel  type. 

6. 3. 3.4  Component  Relation 

The  Component  relation  contains  a  list  of  possible  structural  components  that  form  the  different 
construction  types.  This  makes  it  possible  to  include  new  construction  styles  whenever  necessary, 
without  modifying  the  data  structure. 

6. 3. 3. 5  Drawings  Relation 

The  Drawings  relation  contains  the  structural  drawings  for  a  particular  vessel  class.  It  is  antici¬ 
pated  that  the  drawings  are  stored  in  the  AutoCad^^  drawing  format. 

Structural  drawings  have  the  great  advantage  that  it  is  possible  to  identify  problem  areas  and 
to  determine  detail  locations  in  a  vessel.  However,  the  costs  for  the  generation  of  a  full  set  of 
structural  drawings  for  a  vessel  class  is  very  high.  In  addition,  a  large  amount  of  storage  space  is 
necessary  to  store  the  structural  drawings. 

A  second  problem  with  the  structural  drawings  is  related  to  the  possible  corruption  of  the 
location  data.  In  existing  applications,  CATSIR  and  FracTrac,  a  crack  is  entered  in  the  structural 
drawing  and  is  associated  with  a  record  in  the  database.  This  record  contains  location  related 
information.  It  is,  however,  not  possible  to  guarantee  that  the  location  in  the  AutoCad^-''^  drawing 
matches  the  location  in  the  crack  database. 

This  ambiguity  has  to  be  removed  before  a  full  integration  of  structural  drawings  in  the  vessel 
database  can  be  achieved.  Detail  classes  have  to  be  defined  that  can  accurately  represent  the 
structural  configuration. 

For  a  given  structural  detail,  specific  configuration  in  conjunction  with  the  geometric  dimen¬ 
sions  and  the  location  within  the  vessel  have  to  be  specified.  A  given  detail  can  then  be  associated 
with  a  structural  drawing. 

In  order  to  identify  the  exact  defect  location  in  a  particular  detail,  the  structural  drawing  and 
the  database  information  have  to  be  linked  to  an  even  greater  extent.  Within  the  AutoCad^-*'^ 
drawing,  each  individual  construction  part  has  to  be  coded  in  accordance  with  the  specifications 
given  in  the  database. 

The  above  outlined  requirements  for  a  non-ambiguous  connection  between  the  vessel  database 
and  the  AutoCad^^  drawings,  clearly  shows  the  difficulties  in  the  development  of  this  interface. 
These  difficulties,  together  with  the  other  disadvantages  (cost  and  storage  requirement),  might 
outweigh  the  advantages  of  a  graphical  representation  of  the  ship  structure. 

The  inclusion  of  structural  drawings  in  the  SSIIS  database  structure  will  be  a  political  decision 
based  on  the  potential  usage  of  the  database.  Additional  research  is  necessary  to  provide  sufficient 
information  about  the  actual  benefits  and  disadvantages  of  the  inclusion  of  structural  drawings  in 
the  database. 

6. 3. 3. 6  Frame  Loc  Relation 

The  Frame  Loc  relation  contains  a  table  of  the  frame  locations  for  a  given  class  of  vessels.  Since 
most  of  the  longitudinal  location  information  is  based  on  the  frame  numbers,  this  list  makes  it 
possible  to  determine  the  exact  longitudinal  distribution  of  defects.  This  capability  is  important  for 
the  preparation  of  Critical  Area  Inspection  Plan  (CAIP)  reports  and  other  failure  data  analyses. 

However,  the  use  of  an  explicit  table  for  the  frame  locations  implies  that  transverse  frames 
are  used  to  construct  the  vessel.  Although  this  is  the  pre-dominant  form  of  construction,  other 
construction  types  may  be  introduced  that  make  the  use  of  frame  locations  obsolete.  Additional 
research  is  needed  to  evaluate  the  benefits  of  the  frame  location  table  against  its  possible  limitations. 
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6. 3. 3. 7  S-Long  Loc  Relation 

The  S-Long  Loc  relation  contains  the  transverse  and  vertical  positions  of  the  sideshell  longitudinals 
for  a  given  class  of  vessels.  The  use  of  this  location  information  allows  it  to  show  the  vertical 
distribution  of  defects  in  sideshell  details.  This  is  helpful  for  the  preparation  of  CAIP  reports  and 
other  damage  statistics. 

As  in  the  Frame  Loc  relation,  the  use  of  an  explicit  table  for  the  sideshell  longitudinal  locations 
implies  that  sideshell  longitudinals  are  used  to  construct  the  vessel.  Although  this  is  the  pre¬ 
dominant  form  of  construction,  other  construction  types  may  be  introduced  that  make  the  use  of 
sideshell  longitudinal  locations  obsolete.  Additional  research  is  needed  to  evaluate  the  benefits  of 
the  sideshell  longitudinal  location  table  against  its  possible  limitations. 

6.3.4  Modifications  Module 

6. 3.4.1  Purpose 

The  Modifications  module  is  intended  to  contain  information  with  regard  to  structural  modifi¬ 
cations  to  a  particular  vessel.  By  using  this  separate  module,  it  is  possible  to  conserve  the  history 
of  the  structural  modifications,  which  is  important  for  the  generation  of  CAIP  reports  and  for  the 
general  documentation  of  the  vessel  history. 

Modifications  can  include  the  general  hull  form  (elongations,  etc.),  which  will  also  affect  the 
longitudinal  position  of  the  frame  locations.  In  addition,  modifications  can  be  made  to  the  tank 
arrangement  including  changes  in  the  tank  geometry,  usage,  cathodic  protection  or  coating. 

General  modifications  of  structural  details  are  not  included  in  the  Modifications  module  to 
avoid  conflicts  with  the  Repair  module. 

In  general,  the  information  in  the  Modifications  module  has  to  include  date  information  to 
allow  it  to  reconstruct  the  order  of  structural  modifications  and  to  determine  the  present  configu¬ 
ration.  Additional  research  is  needed  to  determine  the  most  effective  design  and  implementation 
to  represent  structural  modifications. 

The  data  structure  of  the  Modifications  module  is  shown  in  Fig.  (6.5. 

6. 3.4. 2  Hull  Form  Relation 

The  Hull  Form  relation  contains  the  information  pertaining  the  changes  to  the  hull  form  made 
during  the  life  time  of  a  vessel.  In  general,  these  changes  will  consist  of  hull  elongations,  or 
shortening.  The  format  of  the  Hull  Form  relation  in  the  Modifications  module  has  to  be  identical 
to  the  hull  form  description  used  in  the  Design  module  with  the  exception  of  an  added  modification 
date. 


6. 3. 4. 3  Frame  Loc  Relation 

The  Frame  Loc  relation  contains  the  modified  frame  locations  and  the  date  of  the  modifications. 
In  general,  this  information  is  related  to  changes  in  the  Hull  Form  relation. 

An  effective  method  has  to  be  developed  to  account  for  additional  frames,  which  can  change 
the  established  numbering  sequence.  It  will  probably  be  necessary  to  modify  all  frame  location  in 
front  of  a  possible  hull  elongation  point  to  account  for  the  change  in  the  longitudinal  position. 

The  database  management  design  has  to  provide  an  easy  procedure  to  change  the  offsets  of  a 
set  of  frames  by  a  specified  amount  in  order  to  reduce  data  entry  efforts. 

6. 3. 4.4  Tanks  Relation 

The  Tanks  relation  in  the  Modifications  module  contains  the  information  with  regard  to  modified 
tank  geometry,  changed  tank  usage,  changes  in  the  cathodic  protection  system  or  changes  and 
replacements  in  the  coating  system.  Changes  are  documented  using  the  tank  identifications  that 
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are  introduced  in  the  Design  module.  In  addition,  the  date  of  the  changes  is  included,  which 
makes  it  possible  to  establish  the  order  of  the  changes  and  to  identify  the  present  configuration. 

Documenting  the  modifications  to  the  tank  arrangements,  cathodic  protection  and  coating 
system  makes  it  possible  to  develop  the  tank  and  coating  history  documentation  that  is  required 
as  part  of  the  Critical  Area  Inspection  Plan  reports. 

Changes  regarding  the  coating  system  used  in  each  tank  are  contained  in  the  Coating  relation. 
The  modifications  in  the  number  and  type  of  anodes  used  in  ballast  tanks  are  summarized  in 
the  Anodes  relation.  Most  important,  changes  to  the  tank  geometry  description  is  contained  in 
the  Tank  Geometry  relation.  The  subdivision  of  the  tank  modification  information  into  several 
relations  simplifies  the  data  input  and  clarifies  the  overall  data  structure. 

6. 3. 4. 5  Coating  Relation 

The  Coating  relation  contains  information  with  regard  to  the  changes  in  the  coating  of  specific 
tanks,  in  general  only  cargo  tanks.  This  includes  the  coating  material,  the  manufacturer,  the 
humidity  and  temperature  at  the  time  the  coating  was  applied  and  the  coating  thickness. 

For  a  thorough  database  design,  the  material  and  manufacturer  information  should  be  included 
in  an  additional  relation.  This  reduces  input  errors  and  ensures  a  uniform  naming  convention  for 
coating  products.  Only  one  relation  to  contain  this  information  is  needed,  which  can  be  addressed 
both  from  the  Design  and  from  the  Modifications  module. 

Including  the  humidity  and  temperature  makes  it  possible  to  determine  reasons  for  coating 
breakdowns.  Since  the  exposition  to  direct  sunlight  on  the  hull  will  increase  the  temperature,  it 
might  be  desirable  to  include  information  about  possible  heating  effects  due  to  sunlight  in  the 
relation. 


6. 3.4. 6  Anodes  Relation 

The  Anodes  relation  contains  all  the  information  with  regard  to  the  cathodic  protection  used  in 
different  tanks.  This  includes  the  type  and  number  of  anodes,  the  manufacturer  and  the  type  of 
attachment. 

For  a  thorough  database  design,  the  material  and  manufacturer  information  should  be  included 
in  an  additional  relation.  This  reduces  input  errors  and  ensures  a  uniform  naming  convention  for 
anodes  material  and  manufacturers.  Only  one  relation  to  contain  this  information  is  needed,  which 
can  be  addressed  both  from  the  Design  and  from  the  Modifications  module. 

6. 3. 4. 7  Tank  Geometry  Relation 

The  Tank  Geometry  relation  is  linked  to  the  Tcinks  relation  in  the  Modifications  module.  It  is 
intended  to  contain  the  tank  description  for  each  tank  of  a  particular  vessel  that  has  been  modified. 
It  will  in  general  involve  the  offsets  at  both  ends  of  a  tank  and  the  longitudinal  position  of  the 
tank  boundaries.  In  the  case  that  the  tank  shape  changes  in  longitudinal  direction,  the  offsets  and 
longitudinal  position  for  this  change  in  shape  have  also  to  be  included. 

The  data  structure  and  information  contents  of  the  Tank  Geometry  relation  has  to  be  iden¬ 
tical  to  the  Tank  Form  relation  in  the  Design  module  with  the  addition  of  t.  e  date,  when  the 
modifications  where  made. 

The  database  management  system  has  to  be  designed  to  facilitate  a  simple  copy  procedure  of 
the  tank  geometry  information  that  permits  it  to  enter  only  the  changes  in  the  configuration. 

6.3.5  Inspection  Module 
6.3.5. 1  Purpose 

The  Inspection  module  contains  two  sets  of  information.  It  summarizes  all  information  related 
to  individual  inspection  events  including  the  inspection  company,  the  location,  the  inspection  date 
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and  the  individual  inspectors.  In  addition,  the  complete  inspection  results  of  both  corrosion  surveys 
(plate  gaugings)  and  of  structural  surveys  (defects  and  cracks)  are  listed  for  each  inspection  of  a 
particular  vessel. 

The  Inspection  module  is  linked  to  the  Ship,  Class  and  Tank  relations  of  the  Design  module. 
Inspection  results  are  referenced  by  the  ship,  the  vessel  class  and  the  particular  tank.  This  makes 
it  possible  to  include  the  only  partial  inspection  of  a  vessel. 

The  definition  of  the  detail  configuration  for  both  corrosion  and  crack  results  is  based  on  the 
same  detail  definition  procedure.  This  procedure  is  contained  in  the  Detail  sub-module,  which  is 
summarized  in  section  6.3.6. 

For  the  representation  of  the  crack  information,  which  is  most  important  for  the  preparation  of 
Critical  Area  Inspection  Plan  reports,  information  with  regard  to  the  crack  cause,  the  crack  repair 
and  the  crack  class  (as  defined  by  the  U.S.  Coast  Guard)  is  included.  In  addition,  information 
about  the  steel  type  is  included,  which  makes  it  possible  to  investigate  the  effect  of  the  use  of 
High-Tensile-Steel  (HTS)  on  the  development  of  fatigue  cracks. 

In  addition  to  the  detail  configuration,  the  Corrosion  relation  also  contains  information  about 
the  corrosion  type  in  order  to  allow  the  distinction  between  general,  pitting  and  grooving  corrosion. 
The  data  structure  of  the  Inspection  module  is  shown  in  Fig.  (6.6. 

6. 3. 5. 2  Inspection  Relation 

The  Inspection  relation  contains  the  logistic  information  about  all  inspections  that  have  been 
performed.  The  information  is  linked  to  the  Ship  and  Class  relation.  It  contains  the  start  and 
end  dates  of  the  inspection,  the  inspection  company,  the  inspection  location  and  the  inspection 
technicians  (inspectors). 

Most  of  this  information  is  provided  through  the  use  of  additional  relations,  which  reduces 
the  amount  of  data  input  information  and  avoids  input  errors.  Since  it  is  possible  that  several 
inspectors  perform  one  inspection  and  each  inspector  will  be  part  of  several  inspections,  a  many- 
to-many  relationship  is  needed  to  provide  this  information.  This  is  achieved  through  the  use  of  the 
Inspection  -  Inspector  and  the  Inspector  relations. 

For  a  more  complete  database  system  for  the  use  by  operators,  it  might  be  possible  or  desirable 
to  include  information  about  the  inspection  costs.  This  information  can  be  important  for  account¬ 
ing  purposes.  The  duration  of  the  inspection  can  be  obtained  from  the  information  contained  in 
the  Operations  module. 

6. 3. 5. 3  Location  Relation 

The  Location  relation  provides  the  information  regarding  the  location,  where  a  particular  inspec¬ 
tion  is  performed.  This  can  be  a  port  or  during  the  voyage  of  a  vessel. 

The  Location  relation  can  contain  the  name  of  the  port,  possible  points  of  contact,  etc..  This 
information  contents  has  to  be  derived  from  operator  experience  and  preference. 

6. 3. 5.4  Company  Relation 

The  Company  relation  contains  the  information  about  the  company  that  has  performed  the  inspec¬ 
tion.  This  information  can  include  the  name  of  the  company,  the  address,  phone  number,  point  of 
contact  and  any  additional  information  that  can  be  helpful  for  the  documentation  of  the  inspection 
process. 


6. 3. 5. 5  Inspection  -  Inspector  Relation 

The  Inspection  -  Inspector  relation  provides  the  link  between  the  Inspection  and  the  Inspector 
relation,  thus  forming  a  many-to-many  relationship.  It  only  contains  the  primary  keys  of  the  two 
relations.  This  makes  it  possible  that  more  than  one  inspector  can  perform  one  inspection  and  one 
inspector  can  perform  several  inspections. 
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6. 3. 5. 6  Inspector  Relation 

The  Inspector  relation  contains  the  information  with  regard  to  the  different  inspectors.  This  can 
include  the  complete  name,  a  contact  address  and  phone  number  and  any  additional  information 
that  can  be  of  use  for  the  documentation  of  the  inspection  process. 

In  the  present  database  structure,  no  information  about  the  employer  (Inspection  company)  is 
provided  since  this  could  lead  to  data  corruption,  if  the  employer  that  is  specified  does  not  match 
the  company  specified  in  the  Company  relation.  If  the  employer  information  is  considered  to  be 
important,  a  more  complex  structure  has  to  be  devised  that  takes  into  account  the  possibility  that 
an  inspector  can  switch  the  inspection  company. 

6. 3. 5. 7  Corrosion  Relation 

The  Corrosion  relation  contains  the  results  of  corrosion  surveys.  The  relation  is  linked  to  both 
the  Inspection  and  the  Tank  relation.  This  makes  it  possible  to  identify  the  corrosion  survey 
results  for  individual  tanks. 

The  corrosion  type  is  specified  using  an  additional  relation,  the  CorrJType  relation.  The 
Corrosion  relation  contains  the  plate  gauging  results  that  have  been  measured  during  the  survey. 

The  detail  configuration  is  identified  with  the  help  of  the  Detail  sub-module,  described  in 
section  6.3.6.  This  sub-module  is  also  used  in  the  Cracks  relation. 

The  information  about  the  tank  contents,  chemical  composition  of  the  cargo,  tank  tempera¬ 
ture,  etc.,  can  be  found  in  the  Operations  module,  since  this  information  can  change  for  each 
voyage.  The  database  analysis  procedures  that  have  to  be  devised  and  implemented  in  the  database 
management  system  have  to  account  for  these  different  cargo  and  ballast  conditions. 

In  order  to  use  a  direct  link  between  the  gauging  device  and  the  database,  a  system  has  to  be 
developed  that  makes  it  possible  to  define  the  gauging  location  with  sufficient  accuracy  without 
the  use  of  structural  drawings.  This  can  make  it  possible  to  store  the  gauging  results  electronically 
during  the  gauging  process  and  simpy  transfer  them  to  the  database  at  a  later  time. 

6. 3. 5. 8  Corr_Type 

The  CorrJType  relation  contains  the  different  possible  corrosion  types.  This  can  include  general 
corrosion,  pitting  corrosion  and  grooving  corrosion.  This  relation  can  also  include  detailed  de¬ 
scriptions  of  the  different  corrosion  phenomena  and  graphics  or  pictures  that  show  examples  of  the 
different  corrosion  types. 

The  CorrJType  relation  is  linked  to  the  Corrosion  relation  and  minimizes  the  amount  of  data 
input  and  reduces  the  possibilities  for  input  errors. 

6. 3. 5. 9  Cracks  Relation 

The  Cracks  relation  contains  all  the  information  from  the  structural  survey  of  a  vessel  (all  tanks 
or  selected  tanks  only).  The  information  is  provided  for  each  individual  crack.  For  each  crack  the 
crack  causes  can  be  specified  using  a  many-to-many  relationship  to  account  for  the  possibility  of 
several  causes  contributing  to  a  crack. 

For  each  crack  the  crack  class,  as  defined  by  the  U.S.  Coast  Guard,  is  entered.  The  crack 
classes  are  defined  in  an  additional  relation.  Along  with  the  crack  class,  the  actual  crack  length  is 
entered. 

The  steel  type  that  is  used  at  the  particular  crack  location  is  also  specified  in  the  Cracks 
relation.  The  steel  type  specifications  are  contained  in  an  additional  relation  to  minimize  data 
input  and  to  reduce  input  errors. 

For  each  crack,  repair  information  is  specified.  This  can  range  from  simply  re-welding  the  crack 
to  a  complete  re-design.  The  repair  information  is  linked  to  the  Repair  module. 
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Very  important  for  the  analysis  of  fatigue  crack  problems,  the  origin  of  a  crack  is  documented  in 
the  Cracks  relation.  The  possible  origins  are  contained  in  the  Origin  relation  in  order  to  minimize 
data  input  and  to  reduce  input  errors. 

The  definition  of  the  detail  configuration  for  a  particular  crack  incident  is  included  in  the 
Cracks  relation.  The  exact  format  for  the  detail  representation  is  summarized  in  the  section  about 
the  Detail  sub-module,  6.3.6. 

6.3.5.10  Crack  -  Cause  Relation 

The  Crack  -  Cause  relation  provides  the  link  between  the  Cracks  and  the  Cause  relation,  thus 
forming  a  many-io-many  relationship.  It  only  contains  the  primary  keys  of  the  two  relations.  This 
makes  it  possible  that  more  than  one  crack  can  have  several  causes  and  one  cause  can  contribute 
to  many  cracks. 

6.3.5.11  Cause  Relation 

The  Cause  relation  lists  the  different  contributing  factors  that  can  cause  defects.  This  can  include 
corrosion,  fatigue,  design,  manufacturing,  etc..  The  relation  can  include  explanatory  notes  and 
graphics  to  document  the  cause  information.  This  information  can  be  used  to  design  an  online 
help  system  that  can  facilitate  the  data  input. 

6.3.5.12  Crack-Class  Relation 

The  Crack-Class  relation  contains  the  U.S.  Coast  Guard  definitions  for  the  different  crack  classes. 
This  can  include  the  class  name,  the  literal  definition,  a  possible  reference  document  and  a  sketch 
that  describes  the  crack  class  definition. 

One  problem  with  the  crack  class  definition  lies  in  the  fact,  that  a  crack  classification  depends 
both  on  the  crack  length  and  on  the  crack  location.  The  use  of  the  Crack-Class  relation  for  the 
input  of  the  crack  class  does  not  prohibit  that  a  class  might  be  classified  in  the  wrong  class. 

An  improved  design  has  to  ensure  that  the  crack  classification  is  performed  based  on  the  class 
definition  so  that  no  wrong  classifications  can  occur.  Alternatively,  the  classification  can  occur  in 
the  analysis  stage  based  on  the  class  definitions  provided  in  the  Crack-Class  relation. 

6.3.5.13  Steel  Relation 

The  Steel  relation  contains  the  list  of  possible  steel  types  that  can  be  used  in  the  construction  of 
a  detail.  This  minimizes  data  input  and  reduces  possible  input  errors. 

In  the  case  that  the  complete  detail  definition  and  location  procedure  has  been  developed  and 
included  in  the  Construction  module,  which  also  contains  the  steel  type,  the  use  of  the  Steel 
relation  in  the  Inspection  module  becomes  unnecessary. 

6.3.5.14  Origin  Relation 

The  Origin  relation  contains  the  possible  crack  origin.  In  general,  this  will  either  be  the  weld 
between  two  components  or  a  plate  edge.  The  use  of  the  Origin  relation  helps  to  identify  the 
crack  origin  and  can  thus  be  used  to  develop  improved  fatigue  analysis  procedures. 

The  Origin  relation  can  also  contain  graphical  representations  of  the  different  possible  crack 
origins,  which  can  be  used  in  the  design  and  implementation  of  the  database  management  system. 

6.3.5.15  Repair  Relation 

The  Repair  relation  is  used  to  define  the  repair  that  is  performed  for  a  cracked  structural  detail. 
This  relation  is  part  of  the  Repair  module  and  is  described  in  section  6.3.8. 
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6.3.6  Detail  Sub-Module 

6.3.6. 1  Purpose 

The  Detail  sub-module  is  intended  to  define  the  construction  and  components  of  different  struc¬ 
tural  details  in  the  vessel.  This  information  is  used  to  identify  the  structural  detail  that  has 
experienced  a  defect  without  the  help  of  a  structural  drawing. 

The  Detail  sub-module  consists  of  a  series  of  many-to-many  relationships.  Main  structural 
configurations  are  made  up  of  one  (or  several)  built  configurations.  Each  built  configuration  is 
made  of  one  (or  several)  components.  Each  component  can  have  one  (or  several)  defect  sites. 

The  use  of  this  non-graphical  description  of  a  structural  detail  configuration  greatly  facilitates 
the  data  analysis  of  failure  data,  since  the  task  can  be  completely  automated. 

In  a  future  development,  it  has  to  be  investigated,  whether  it  is  possible  to  combine  this 
structural  detail  definition  with  geometric  dimensions  and  the  location  information  within  the 
vessel  to  completely  describe  the  vessels  main  structural  configuration  and  critical  structural  details 
without  the  use  of  structural  drawings.  This  would  make  it  possible  to  develop  procedures  to 
automatically  create  finite  element  models  for  a  specific  structural  detail  at  a  given  location. 

The  finite  element  model  generation  could  be  based  on  the  procedure  developed  as  part  of  the 
Structural  Maintenance  Project  (SMP).  See  [40]  and  [31]  for  a  description  of  the  mesh  generation 
software  developed  as  part  of  the  SMP  project. 

6. 3. 6. 2  Main  Relation 

The  Main  relation  contains  a  list  of  the  different  main  structural  configurations  in  a  vessel.  By 
linking  it  to  the  Built  relation  through  a  many-to-many  relationship,  it  is  possible  that  each  main 
structural  configuration  can  be  composed  of  several  built  details. 

In  addition  to  the  several  built  components,  the  Main  relation  can  contain  a  graphical  repre¬ 
sentation  of  the  main  structural  configuration.  This  graphical  representation  can  be  used  in  the 
database  management  system  to  facilitate  data  input  procedures  and  to  developed  a  customized 
help  system  that  is  based  partly  on  database  information  and  is  thus  very  flexible. 

6. 3. 6. 3  Main  -  Built  Relation 

The  Main  -  Built  relation  provides  the  link  between  the  Main  and  the  Built  relation,  thus  forming 
a  many-to-many  relationship.  It  only  contains  the  primary  keys  of  the  two  relations.  This  makes 
it  possible  that  more  than  one  Built  structure  can  be  used  for  one  main  structural  configuration 
and  each  built  component  can  be  part  of  several  main  structural  configurations. 

6. 3. 6.4  Built  Relation 

The  Built  relation  contains  the  different  smaller  structural  details  that  are  built  from  one  or  many 
different  components.  The  Built  relation  is  linked  to  the  Component  relation  in  a  many-to-many 
relationship,  thus  permitting  one  built  structure  to  contain  several  individual  components  and  each 
component  to  be  part  of  several  built  structures. 

In  addition  to  the  name  of  the  built  component  it  is  possible  to  include  a  graphical  representa¬ 
tion  of  the  built  structural  detail  and  a  verbal  description.  This,  again,  makes  it  possible  to  develop 
data  input  screens  within  the  database  management  system  that  can  use  graphical  information  to 
facilitate  data  input. 

6. 3. 6. 5  Built  -  Comp  Relation 

The  Built  -  Comp  relation  provides  the  link  between  the  Built  and  the  Comp  relation,  thus  forming 
a  many-to-many  relationship.  It  only  contains  the  primary  keys  of  the  two  relations.  This  makes 
it  possible  that  more  than  one  component  can  be  used  for  one  built  structure  and  each  component 
can  be  part  of  several  built  structures. 
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6. 3. 6. 6  Component  Relation 

The  Component  Relation  contains  the  individual  components  that  are  used  to  describe  the  Built 
structural  details.  This  can  include  the  flange  and  the  web  of  a  built  longitudinal  or  the  cutout  of 
a  webframe. 

Each  component  can  have  one  or  more  defect  sites.  These  sites  identify  the  possible  areas  in 
a  component,  where  a  defect  can  be  located.  This  information  can  be  used  to  clearly  determine 
the  defect  location.  A  many-to-many  relationship  is  used  to  identify  these  defect  sites,  since  it  is 
possible  that  one  component  has  more  than  one  defect  site  and  each  defect  site  can  be  used  in 
many  components. 

In  addition  to  the  name  of  the  component  it  is  possible  to  include  a  graphical  representation 
of  the  component  and  a  verbal  description.  This,  again,  makes  it  possible  to  develop  data  input 
screens  within  the  database  management  system  that  can  use  graphical  information  to  facilitate 
data  input. 

6. 3. 6. 7  Comp  -  Site  Relation 

The  Comp  -  Site  relation  provides  the  link  between  the  Comp  and  the  Site  relation,  thus  forming 
a  many-to-many  relationship.  It  only  contains  the  primary  keys  of  the  two  relations.  This  makes 
it  possible  that  more  than  one  defect  site  can  be  used  for  one  component  and  each  defect  site  can 
be  used  in  many  components. 

6. 3. 6. 8  Defect-Site  Relation 

The  Defect-Site  relation  contains  the  information  about  the  possible  defect  sites.  This  includes 
the  name  of  the  defect  sites,  a  description  and  possibly  a  graphical  representation. 

The  defect  site  information  is  used  to  identify  the  main  location  of  a  defect.  In  addition,  the 
Origin  relation  in  the  Cracks  module  identifies  the  exact  origin  of  a  crack.  Although  these  two 
locations  can  coincide,  the  use  of  the  additional  defect  site  information  can  account  for  the  fact 
that  the  crack  originates  at  one  location  (the  origin),  but  has  propagated  in  a  different  location 
(the  defect  site). 

6.3.7  Maintenance  Module 

6. 3. 7.1  Purpose 

The  Maintenance  module  contains  the  information  about  vessel  maintenance.  This  includes 
engine,  coating  and  anodes  maintenance.  It  is  different  from  the  information  contained  in  the 
Modifications  module,  since  only  actual  maintenance  is  included,  such  as  the  replacement  of 
anodes,  the  renewal  of  coating  and  standard  engine  maintenance. 

All  information  is  linked  to  the  Ship  and  the  Class  relation.  In  addition,  for  the  anodes  and 
coating  maintenance,  a  link  to  the  Tanks  relation  is  also  established.  For  each  tank  in  a  vessel,  it 
is  therefore  possible  to  determine  the  maintenance  history.  This  is  particularly  important  for  the 
generation  of  Critical  Area  Inspection  Plan  reports. 

Additional  research  and  input  from  potential  database  users  is  needed  to  further  develop  the 
data  formats  and  information  contents  of  this  module. 

6. 3. 7. 2  Engine  Relation 

The  Engine  relation  contains  all  necessary  information  about  the  routine  engine  maintenance.  This 
can  include  a  list  of  replaced  parts,  lubrication  procedures,  retrofitted  components,  etc.. 

The  engine  maintenance  information  depends  strongly  on  operator  and  engine  manufacturer 
requirements.  Additional  research  is  needed  to  clearly  determine  the  scope  and  information  content 
of  the  Engine  relation 
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6. 3. 7. 3  Coating  Relation 

The  Coating  relation  contains  the  information  about  the  regular  coating  maintenance.  This  in¬ 
cludes  complete  re-coating  of  tanks  or  the  fix-up  of  small  areas  of  coating  breakdown. 

In  the  case  that  a  different  coating  procedure  is  used,  this  information  has  to  be  entered  in 
the  Modifications  module,  since  it  constitutes  a  change  of  the  vessel  configuration.  Nevertheless, 
material  information  is  entered  in  order  to  provide  complete  maintenance  information. 

A  separate  relation  is  used  to  provide  the  material  information.  This  relation  can  also  be  used 
for  the  coating  information  in  the  Design  and  the  Modifications  modules.  This  ensures  data 
integrity  and  prohibits  data  input  errors. 

6. 3. 7.4  Material  Relation 

The  Material  relation  contains  the  information  about  the  different  coating  materials.  This  can 
include  the  name,  the  manufacturer,  the  chemical  composition,  and  other  technical  information. 

In  addition,  usage  requirements,  such  as  maximum  humidity  or  minimum  temperatures  can  be 
entered  here.  This  makes  this  information  readily  accessible  and  can  be  used  for  data  analysis  and 
reporting  purposes. 

6. 3. 7. 5  Anodes  Relation 

The  Anodes  relation  contains  all  information  about  the  replacement  of  anodes.  Information  about 
the  anode  type  is  obtained  from  the  Type  relation.  The  Anodes  relation  does  not  contain  informa¬ 
tion  about  the  new  installation  of  anodes  in  tank  that  were  originally  without  cathodic  protection. 
This  type  of  information  is  included  in  the  Modifications  module. 

6. 3. 7. 6  Type  Relation 

The  Type  relation  contains  the  information  about  the  different  anode  types.  This  can  include 
the  name,  the  manufacturer,  the  chemical  composition,  the  anode  dimensions  and  other  technical 
information. 

In  addition,  usage  requirements,  such  as  maximum  humidity  or  minimum  temperatures  can  be 
entered  here.  This  makes  this  information  readily  accessible  and  can  be  used  for  data  analysis  and 
reporting  purposes. 

6.3.8  Repair  Module 
6.3.8. 1  Purpose 

The  purpose  of  the  Repair  module  is  to  document  structural  repairs  in  tankers.  It  is  linked  to  the 
Inspection  module.  This  makes  it  possible  to  clearly  document  the  repairs  to  a  particular  failure 
including  detailed  drawings. 

The  module  includes  crack  repairs  and  steel  renewal  information.  The  steel  renewal  informa¬ 
tion  is  important  to  assess  the  structural  integrity  of  a  vessel  and  to  assure  that  the  vessel  is  in 
accordance  with  classification  requirements. 

Additional  research  is  needed  to  clearly  define  the  functionality  and  the  interfacing  between 
the  Repairs  and  the  Inspection  module.  Especially  important  is  the  issue  of  repairs  of  previously 
repaired  details.  In  order  to  asses  the  quality  and  efficiency  of  a  repair,  it  is  necessary  to  identify 
successful  and  unsuccessful  repairs. 

A  second  important  area  for  further  development  is  the  documentation  of  repair  times  and 
itemized  repair  costs.  This  information  can  help  to  determine  the  most  appropriate  repair  based 
on  economic  considerations. 
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6. 3. 8. 2  Repair  Relation 

The  Repair  relation  contains  information  about  crack  repairs  and  steel  renewals.  It  is  linked  to 
the  Cracks  relation  in  the  Inspection  module.  For  crack  repairs,  the  detail  has  to  be  identified, 
particularly  in  cases,  where  the  repair  consists  of  a  detail  re-design.  In  addition,  the  repair  type 
has  to  be  specified  and  a  structural  drawing  can  be  used  to  document  the  repair. 

Steel  renewal  information  is  also  included  in  the  Repair  relation.  For  steel  renewal,  only 
structural  drawings  are  used  to  document  the  repair.  Additional  development  is  needed  to  link 
the  steel  renewal  information  to  the  Corrosion  relation  in  the  Inspection  module  and  to  provide 
sufficient  detail  about  the  location  and  the  type  of  steel  renewal. 

6. 3. 8. 3  Crack-Repair  Relation 

The  Crack-Repair  relation  provides  detailed  information  about  the  repair  of  a  particular  crack 
that  has  been  included  in  the  Cracks  relation  of  the  Inspection  module.  The  type  of  structural 
detail  is  documented  including  possible  changes  in  the  original  design.  The  crack  location  is  already 
included  in  the  Cracks  relation  and  does  not  have  to  be  repeated.  Based  on  information  stored  in 
the  Repair -Type  relation,  the  method  that  has  been  used  to  repair  the  crack,  is  documented.  A 
structural  drawing  can  be  included  that  identifies  the  repair. 

Additional  development  is  needed  to  determine  a  possible  format  that  can  provide  information 
with  regard  to  the  cost  and  duration  of  a  particular  repair.  This  information  can  be  used  to 
determine  the  optimum  repair  solution  based  on  economic  considerations  using  a  probabilistic 
analysis  procedure. 

The  detailed  format  that  can  be  used  to  document  repairs  to  cracked  details  depends  strongly 
on  the  detail  representation  that  is  used  in  the  Detail  sub-module.  The  development  of  these  two 
formats  is  therefore  strongly  connected. 

6. 3. 8. 4  Repair-Type  Relation 

The  Repair-Type  relation  consists  of  a  standardized  documentation  of  the  different  possible  repair 
solutions.  This  has  to  include  a  repair  name,  a  repair  definition,  a  description  of  the  purpose  and 
advantages  of  the  repair  and  a  graphical  representation  of  the  repair  method. 

The  development  of  the  Repair  relation  can  form  the  basis  for  a  future  knowledge  based 
system  that  can  assist  users  in  the  selection  of  the  most  appropriate  repair.  In  conjunction  with 
this  knowledge  based  system,  the  importance  of  obtaining  information  with  regard  to  repair  costs 
and  repair  durations  has  to  be  stressed  again. 

6.3.8. 5  Drawing  Relation 

The  Drawing  relation  contains  the  graphical  representation  of  the  actual  repair  including  detail 
dimensions.  The  link  of  this  information  to  the  Crack  relation  makes  it  possible  to  draw  conclusions 
with  regard  to  the  repair  effectiveness  and  to  document  particular  crack  repairs,  as  is  required  for 
severe  cracks  in  Critical  Inspection  Areas. 

The  drawing  format  has  to  follow  the  same  standards  as  the  general  structural  drawings  in  the 
Construction  module.  This  assures  a  smooth  interface  between  the  different  database  modules, 
which  is  particularly  important  for  the  reporting  and  query  features  of  the  database  management 
system. 

6. 3. 8. 6  Steel-Renewal  Relation 

The  Steel-Renewal  relation  is  intended  to  contain  information  relating  to  the  replacement  of 
corroded  plating.  This  has  to  include  the  plating  location,  the  dimensions  and  the  weight  of  the 
replaced  plating. 


99 


In  addition,  the  cost  of  the  steel  replacement  and  the  required  time  has  to  be  recorded.  This 
information  can  help  for  the  future  planning  of  repair  and  maintenance  operations  and  can  help 
to  determine  the  optimum  maintenance  strategy. 

6.3.9  Operations  Module 

6. 3. 9.1  Purpose 

The  Operations  module  has  the  purpose  to  provide  information  about  all  relevant  aspects  of 
tanker  operations.  This  information  is  intended  for  a  wide  variety  of  users  and  contains  therefore 
very  diverse  information. 

The  data  is  organized  based  on  individual  voyages.  Each  voyage  consists  of  several  legs. 
For  each  leg  the  departure  and  destination  port  is  identified.  Cargo  information  can  be  entered 
individually  for  each  leg. 

The  information  about  the  crew  for  each  leg  can  be  of  interest  for  accouting  and  general 
bookkeeping  purposes.  The  information  contents  with  regard  to  the  crew  has  to  be  defined  based 
on  the  need  and  general  practice  of  tanker  operators. 

In  general,  the  Operations  module  has  to  be  refined  and  expanded  in  order  to  make  it  a 
useful  tool  for  day-today  operations  and  extended  analysis  of  operating  procedures.  Significant 
input  from  tanker  operators  is  needed  to  complete  this  task. 

The  accurate  and  complete  collection  and  storage  of  operations  related  information  and  its 
subsequent  use  for  planning  and  management  purposes  can  provide  sufficient  incentives  for  tanker 
operators  to  use  a  general  vessel  information  system.  The  development  of  the  Operations  module 
is  therefore  of  the  greatest  importance  in  order  achieve  a  wide  acceptance  of  the  SSIIS  database 
system. 


6. 3. 9. 2  Voyage  Relation 

The  Voyage  relation  constitutes  the  core  of  the  Operations  module.  All  operations  related  infor¬ 
mation  is  organized  based  on  individual  voyages.  Each  voyage  is  comprised  of  several  VoyageJLegs, 
which  makes  it  possible  to  identify  all  ports  and  destinations  and  to  determine  the  cargo  type  and 
loading  conditions  for  the  individual  legs. 

For  each  day  of  a  voyage,  a  daily  report  is  stored  that  summarizes  the  weather  conditions,  the 
engine  particulars  and  the  noon  position  of  the  vessel.  This  information  can  be  very  helpful  to 
determine  long-term  loadings,  evaluate  engine  performance  and  determine  average  speeds. 

The  voyage  relation  is  linked  to  the  Ship  and  the  Class  relation.  Voyages  are  therefore  stored 
for  each  vessel  of  each  class.  The  use  of  voyages  as  the  main  definition  of  the  travel  service  pattern 
makes  it  possible  to  determine  a  vessel’s  primary  trade  route,  but  is  also  flexible  enough  to  recognize 
changes  in  this  trade  route. 

6. 3. 9. 3  Noon-Reports  Relation 

The  Noon-Reports  relation  contains  daily  reports  about  weather,  engine  and  vessel  position.  This 
information  is  contained  in  three  additional  relations.  The  Noon-Reports  relation  electronically 
stores  information  that  is  presently  gathered  and  stored  onboard  of  the  vessel  and  is  then  transferred 
to  the  operator  headquarters. 

Presently,  some  operators  are  implementing  electronic  database  system  for  the  storage  of  this 
operations  related  information,  see  section  4.4  for  the  description  of  the  Vessel  Management  system 
(VMS)  that  is  currently  being  developed  by  Chevron. 

The  noon  reports  are  organized  by  vessel  and  vessel  class  and  the  date,  since  only  one  report 
can  exist  for  one  vessel  of  a  particular  class  for  any  given  date. 


100 


6. 3. 9.4  Weather  Relation 


The  Weather  relation  contains  a  summary  of  the  weather  condition  for  each  day.  This  can  include 
the  average  temperature,  the  wind  speed  and  direction  and  barometric  pressure.  The  purpose  of 
this  relation  is  to  provide  sufficient  information  to  allow  a  correlation  between  the  weather  and  the 
ship  monitoring  information  contained  in  the  Monitoring  module, 

In  addition  to  the  general  weather  information,  it  is  important  to  include  data  about  the  sea 
state.  This  should  include  the  average  wave  height  and  wave  direction.  It  has  to  be  investigated, 
whether  this  type  of  information  is  currently  gathered  by  the  vessel  crew  and  what  information 
can  be  obtained  with  minimal  effort. 

Appendix  D  contains  the  information  that  is  included  in  the  noon  position  reports  that  are 
part  of  the  VMS  database  system.  This  information  can  be  used  as  guidelines  for  the  development 
of  the  Weather  relation. 

Additional  research  is  needed  to  define  the  most  appropriate  format  for  the  Weather  relation. 
This  research  has  to  determine  the  data  needs  of  vessel  operators  and  engineers  and  to  evaluate 
the  data  needs  against  the  economic  factors. 

6. 3. 9. 5  Engine  Relation 

The  Engine  relation  contains  all  relevant  information  about  the  general  engine  performance  for  each 
day  of  a  voyage.  This  information  can  be  used  to  evaluate  engine  performance  and  to  accurately 
document  the  use  of  the  engine. 

The  information  has  to  include  the  average  RPM,  the  fuel  consumption,  the  use  of  lubrication 
oil  and  any  other  relevant  engine  related  information.  Based  on  the  information  contained  in  the 
Engine  relation,  it  is  possible  to  determine  the  total  engine  usage  and  thus  effectively  schedule 
maintenance  intervals. 

Appendix  D  contains  the  information  that  is  included  in  the  noon  position  reports  that  are 
part  of  the  VMS  database  system.  This  information  can  be  used  as  guidelines  for  the  development 
of  the  Engine  relation. 

6. 3. 9. 6  Position  Relation 

The  Position  relation  contains  the  exact  noon  position  of  the  vessel.  Additional  information  as 
the  daily  miles  and  the  course  can  be  included.  The  noon  position  can  be  used  to  accurately 
determine  the  vessels  average  course  and  average  speed.  It  can  also  be  used  to  determine  the 
general  ocean  areas  through  which  the  vessel  has  travelled.  This  information  is  needed  in  order  to 
determine  the  long-term  load  distribution  bcised  on  generalized  wave  scatter  diagrams. 

6. 3. 9. 7  Leg  Relation 

The  Leg  relation  contains  all  information  that  is  specific  for  one  leg  of  a  voyage.  The  relation  is 
linked  to  the  Voyage  and  the  Ship  and  Class  relations.  This  assures  that  the  different  voyage  legs 
of  a  particular  vessel  can  be  accurately  re-constructed. 

In  addition  to  the  ship  and  the  class  information,  the  departure  date  and  arrival  date  is 
included.  The  departure  date  is  used  as  the  primary  key  in  conjunction  with  the  ship  and  the  class 
information.  The  database  management  system  has  to  ensure  data  integrity  by  requiring  that  the 
departure  date  for  a  new  leg  of  a  vessel  is  later  than  the  latest  arrival  date  for  that  vessel. 

6. 3. 9. 8  Ports  Relation 

The  Ports  relation  contains  a  list  of  ports  and  terminals  that  are  used  by  the  different  vessels. 
This  includes  the  exact  location,  information  about  draft  limitations  and  the  type  of  discharge 
facilities. 
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The  Ports  relation  has  to  be  developed  further  based  on  input  from  tanker  operators.  It  could 
include  a  list  of  the  available  moorings  and  docks  in  each  port,  which  could  be  used  to  correlate 
discharge  and  general  harbor  time  with  the  type  of  mooring  facility. 

6. 3. 9. 9  Cargo  Relation 

The  Cargo  relation  contains  the  information  about  the  exact  cargo  for  one  leg.  This  information 
includes  the  water  and  sulphur  contents  of  the  cargo,  and  the  cargo  temperature. 

In  order  to  obtain  more  detailed  information,  the  Cargo  relation  can  be  linked  to  the  Tanks 
relation  and  the  cargo  information  can  then  be  provided  for  each  individual  tank. 

Cargo  information  can  also  include  economic  data  used  for  general  decision  making.  Coop¬ 
eration  with  tanker  operators  is  necessary  to  define  the  full  information  contents  of  the  Cargo 
relation. 


6.3.9.10  Loading  Relation 

The  Loading  relation  contains  the  loading  status  for  each  tank.  The  includes  the  filling  level,  the 
amount  of  cargo  or  ballast  in  the  tank  and  any  additional  information  that  is  related  to  the  tank 
loading. 

In  general,  this  information  can  be  obtained  from  the  output  of  different  loading  software,  e.g. 
CARGOMAX.  Evaluating  the  information  contents  of  CARGOMAX  and  through  discussions  with 
tanker  operators,  a  more  complete  information  contents  for  the  Loading  relation  can  be  developed. 

6.3.9.11  Leg  -  Crew  Relation 

The  Leg  -  Crew  relation  relation  provides  the  link  between  the  Leg  and  the  Crew  relation,  thus 
forming  a  many-to-many  relationship.  It  only  contains  the  primary  keys  of  the  two  relations.  This 
makes  it  possible  that  many  crew  members  can  be  on  a  vessel  during  one  leg  and  each  crew  member 
can  be  on  different  legs. 

6.3.9.12  Crew  Relation 

The  Crew  relation  contains  information  about  the  vessel  crew.  This  information  is  intended  both 
for  the  vessel  operation  and  for  accounting  and  personnel  purposes.  It  has  to  include  the  name  and 
address  of  the  crew  member,  his  expertise  and  position  onboard  of  a  vessel  and  general  accounting 
information. 

Cooperation  with  the  accounting  departments  of  tanker  operators  is  necessary  to  develop  a 
functional  Crew  relation  that  contains  sufficient  and  useful  information  about  crew  members. 

6.3.10  Monitoring  Module 
6.3.10.1  Purpose 

The  purpose  of  the  Monitoring  module  is  to  contain  the  results  from  vessel  monitoring  programs. 
These  programs  measure  different  vessel  response  characteristics  at  constant,  short  time  intervals 
during  each  voyage.  Vessel  monitoring  devices  are  currently  being  installed  on  many  different 
tankers.  Monitoring  can  help  to  reduce  damage  to  a  vessel  by  providing  information  about  high 
loads  on  a  vessel  due  to  a  storm,  thus  allowing  the  vessel  crew  to  react  by  redncing  speed  and  /  or 
changing  course. 

In  addition  to  the  short  term  benefits  of  vessel  monitoring  to  detect  and  avoid  critical  peak 
loads,  it  can  also  be  used  to  document  and  re-create  the  long-term  loading  history  of  a  vessel.  This 
is  of  utmost  importance  for  the  estimation  of  fatigue  damage  on  a  vessel. 

Additional  research  is  necessary  to  determine  the  most  appropriate  format  to  store  the  re¬ 
sponse  information.  This  format  will  be  a  trade-off  between  information  accuracy  and  storage 
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requirements.  The  maximum  time  interval  between  individual  response  measurements  has  to  he 
determined.  Due  to  the  large  amount  of  data  that  can  be  gathered,  a  method  has  to  be  developed 
to  calculate  and  summarize  the  data  and  then  to  store  only  the  summaries.  This  can  maybe  be 
done  by  estimating  the  response  spectra  for  subsequent  2-3  hour  periods  and  to  store  only  the 
spectrum  parameters. 

However,  it  is  believed  that  the  use  of  monitoring  data  can  lead  to  improved  loading  estimates 
for  vessels  and  a  more  accurate  representation  of  the  loading  over  the  lifetime  of  a  vessel. 

6.3.10.2  Response  Relation 

The  Response  relation  contains  all  the  response  information  for  a  given  vessel,  vessel  class  and 
voyage.  It  is  therefore  linked  to  the  Ship,  Class  and  Voyage  relations.  It  has  to  contain  sufficient 
information  to  allow  the  calculation  of  the  long-term  vessel  loading  history. 

In  addition,  it  has  to  be  possible  to  trace  the  monitoring  methods  that  are  used,  including 
equipment,  sampling  periods,  company,  etc. This  will  make  it  possible  to  backtrack  and  evaluate 
different  procedures  and  to  determine  the  effectiveness  of  monitoring  equipment. 

Additional  research  is  needed  to  fully  develop  the  contents  of  the  Response  relation.  This  will 
involve  additional  literature  studies,  discussions  with  operators  and  monitoring  companies  and  the 
development  of  suitable  performance  standards. 

6.3.10.3  Location  Relation 

The  Location  relation  contains  a  list  of  the  different  locations  that  are  used  for  the  response 
measurements.  This  information  is  necessary  to  accurately  identify  the  different  response  charac¬ 
teristics  and  to  calculate  the  long-term  loading  for  a  vessel. 

The  Location  relation  can  be  expanded  to  use  some  of  the  more  advanced  location  descriptors 
used  to  identify  defect  locations.  This  can  help  to  unify  the  location  descriptions  and  to  cross- 
reference  defect  and  loading  locations. 

6.3.10.4  Acceleration  Relation 

The  Acceleration  relation  contains  the  accelerations  for  a  given  vessel  of  a  class  for  a  specific 
voyage.  The  accelerations  are  listed  for  specific  locations  that  are  identified  in  the  Locations 
relation. 

The  exact  format  of  the  Accelerations  relation  has  to  be  developed  in  more  detail.  This 
development  has  to  address  the  current  ship  monitoring  practice  and  define  ways  to  compress  the 
monitoring  results  to  conserve  storage  space. 

6.3.10.5  Pressure  Relation 

The  Pressure  relation  contains  the  pressures  for  a  given  vessel  for  a  specific  voyage.  Similar  to 
the  Acceleration  relation,  the  format  for  the  Pressure  relation  has  to  be  defined  in  more  detail. 

The  exact  procedure  to  determine  pressures  on  specific  locations  on  the  ship  hull  has  to  be 
investigated.  The  results  of  this  investigation  will  determine  the  most  suitable  format  and  the  data 
contents  for  the  Pressure  relation. 

6.3.10.6  Stress  Relation 

The  Stress  relation  contains  the  stresses  that  have  been  measured  using  strain  gauges  at  specific 
locations  on  structural  details  on  the  ship.  These  strain  measurements  serve  two  purposes,  they  are 
used  to  alert  the  vessel  crew  of  possible  extreme  conditions,  where  the  material  yield  is  exceeded 
and  they  are  used  to  determine  the  transfer  functions  between  the.  environmental  loading  and  the 
stress  response. 


103 


Additional  research  is  needed  to  determine  the  exact  format  and  information  contents  for  the 
Stress  relation.  This  has  to  include  the  definition  of  the  exact  location  of  the  strain  gauges,  which 
exceeds  the  information  in  the  Location  relation. 


6.4  Database  Management  System  for  SSIIS 

6.4.1  Overview 

The  developed  database  structure  that  contains  all  necessary  information  with  regard  to  tanker 
survey  results  is  intended  to  replace  the  present  form  of  storage  for  survey  results  and  ship  in¬ 
formation,  which  implies  that  the  database  structure  will  be  used  in  day-to-day  operations  by 
owner/operators.  This  requires  the  development  of  a  database  management  system  (DBMS)  that 
facilitates  these  operations.  This  DBMS  has  to  meet  the  following  requirements: 

•  The  system  has  to  have  a  graphical  user  interface  that  makes  all  database  operations  easy 
to  use. 

•  Input  screens  for  all  data  structures  that  are  ship  or  survey  related  have  to  be  available  to 
perform  input  of  new  data. 

•  The  system  has  to  have  editing  capabilities  that  allow  the  modification  of  existing  data. 

•  The  data  input  procedures  have  to  permit  only  valid  data.  This  requires  that  drop-down 
lists  are  available  that  only  allow  the  choice  among  available  information,  e.g.  corrosion 
information  can  only  be  entered  for  a  ship  that  is  included  in  the  database,  i.e.  the  VesseUD 
has  to  be  chosen  among  the  available  VesseUD. 

•  Analysis  and  query  capabilities  have  to  be  included  in  the  system.  The  system  has  to  allow 
the  generation  of  customized  queries  in  order  to  provide  a  flexible  tool  that  can  be  adapted 
to  changing  evaluation  needs. 

•  The  system  has  to  provide  standardized  reports  that  can  be  generated  with  a  minimum  of 
user  input  in  order  to  guarantee  a  consistent  report  format  that  meets  given  standards  and 
recommendations.  For  the  SSIIS  project,  the  most  important  report  format  requirement  is 
the  Critical  Area  Inspection  Plan  report  format  that  has  been  outlined  in  chapter  5. 

The  prototype  development,  documented  in  chapter  7  contains  a  basic  DBMS,  which  is  intended 
to  provide  an  example  for  the  general  design  and  implementation  of  a  database  management  system. 

As  shown  in  Fig.  (6.1)  the  DBMS  and  the  Vessel  Database  form  the  overall  SSIIS  system.  The 
developed  database  structure  is  documented  in  section  6.3.  The  DBMS  uses  the  vessel  database  and 
performs  all  the  necessary  database  manipulations,  and  all  data  input  and  output  functions. 

The  purpose  of  the  DBMS  can  be  subdivided  into  three  main  modules: 

•  Administration 

•  Data  Input,  Data  Edit 

•  Queries,  Reports 

Fig.  (6.12)  shows  a  more  detailed  summary  of  the  database  management  system.  For  each  of 
the  three  categories,  the  necessary  components  are  defined.  In  the  following  sections,  the  different 
components  for  each  of  the  three  main  module  are  summarized  and  described. 
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6.4.2  Administration 

6. 4. 2.1  Purpose 

The  Administration  module  of  the  DBMS  has  to  ensure  the  database  integrity,  provide  system 
security,  and  allow  a  customized  setup  of  the  database.  Additional  features  that  are  of  importance 
for  the  overall  functionality  of  the  database  will  be  included  in  this  module  in  the  course  of  the 
development. 

A  sophisticated  database  administration  can  prevent  data  losses  due  to  corrupted  input  data 
and  can  provide  the  password  protection  of  sensitive  parts  of  the  database.  This  is  particularly 
important  for  a  general  database  system  such  as  the  SSIIS  databeise.  It  has  to  be  assured  that  data 
can  be  accessed  by  authorized  users  only.  The  database  administration  has  to  be  able  to  allow 
access  to  selected  areas  only. 

6.4. 2. 2  User  Privileges 

The  SSIIS  database  system  consists  of  a  large  amount  of  data  that  is  used  for  a  wide  variety  of 
purposes.  It  has  to  be  assured  that  each  user  has  only  access  to  a  defined  part  of  the  database.  The 
database  administrtation  has  to  provide  access  to  any  part  of  the  database  for  individual  users. 
The  user  privileges  and  password  protection  have  to  be  able  to  be  changed  or  revoked  at  any  time. 

A  list  function  that  identifies  all  authorized  users  and  their  individual  privileges  has  to  be 
available  to  the  database  administrator.  This  makes  it  possible  to  get  an  overview  about  all 
database  users  and  to  identify  the  different  privilege  levels. 

The  implementation  of  the  user  privileges  strongly  depends  on  the  general  SSIIS  structure, 
the  hardware  and  operating  system  and  the  database  software  used  to  create  SSIIS.  In  addition, 
other  existing  large  database  systems  (i.e.  FAA  database)  have  to  be  studied  to  determine  the  most 
efficient  implementation. 

6.4. 2. 3  Database  Integrity 

Through  extensive  use  and  data  input  and  data  deletion,  it  is  possible  that  a  database  becomes 
corrupted.  Data  indexes  are  not  coherent  any  longer  and  previously  used  storage  space  does  not 
get  reallocated.  This  status  can  be  detrimental  to  the  database  performance  and  can  possibly  lead 
to  data  corruption. 

It  is  therefore  necessary  for  the  database  administrator  to  perform  database  maintenance  op¬ 
erations  that  involve  data  backup  and  a  complete  reallocation  of  storage  capacities. 

The  database  maintenance  functions  have  to  be  password  protected  to  assure  that  only  autho¬ 
rized  users,  in  general  the  database  administrator,  is  able  to  perform  the  operations. 

6.4. 2.4  Database  Setup 

The  database  setup  functions  include  the  possibility  to  customize  input  screens  and  include  cus¬ 
tomized  Help  information.  In  addition,  any  company  specific  additions  to  the  general  database 
setup  have  to  be  included  here. 

6.4.3  Data  Input  /  Edit 
6.4.3. 1  Purpose 

The  Data  Input  and  Data  Edit  capabilities  form  the  core  of  the  DBMS.  One  of  the  main 
functions  of  any  database  system  is  the  storage  of  data.  The  input  and  manipulation  of  data  is 
therefore  one  of  the  main  functions  that  a  DBMS  has  to  provide. 
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6.4. 3. 2  Data  Import 

In  many  cases,  data  is  gathered  and  stored  on  a  different  database  system.  In  order  to  avoid 
unnecessary,  repetitive  input,  the  DBMS  has  to  provide  data  import  facilities  that  make  it  pos¬ 
sible  to  translate  data  from  different  database  system  to  the  SSIIS  format.  In  many  cases,  these 
translation  routines  have  to  be  customized  for  specific  problems.  The  DBMS  has  to  provide  the 
general  functionality  that  makes  it  possible  to  implement  these  customized  translation  procedures. 

6. 4. 3. 3  System  Data 

The  SSIIS  database  structure  contains  many  relations  for  information  that  has  to  be  entered  only 
at  the  initialization  of  the  database  and  will  rarely  need  to  be  revised  or  modified.  However,  input 
procedures  and  input  screens  have  to  be  available  to  enter  this  system  data. 

The  input  procedures  for  the  system  data  can  be  grouped  together.  This  makes  it  possible  to 
assign  user  privileges  for  this  data  entry  routines  in  an  easy  manner,  since  this  data  should  only 
be  entered  or  modified  by  especially  authorized  users. 

6.4. 3.4  Vessel  Data 

The  vessel  data  has  to  be  entered  for  each  new  vessel  that  is  entered  in  the  system.  For  vessels 
that  have  sister  ships  that  are  already  in  the  database,  the  data  input  is  minimal.  For  a  new  class 
of  vessels,  the  complete  hull,  tank,  and  structural  information  has  to  be  entered. 

The  data  input  screens  and  procedures  have  to  be  designed  in  a  form  that  makes  it  fast  and 
efficient  to  enter  a  new  vessel  class  into  the  database.  The  use  of  graphical  tablets  to  enter  the  hull 
form  has  to  be  investigated.  Clear  guidelines  for  the  preparation  and  use  of  structural  drawings 
have  to  be  developed  in  order  to  limit  the  necessity  to  generate  specialized  structural  drawings 
only  for  the  vessel  database. 

6.4. 3. 5  Operational  Data 

The  input  of  operational  data  forms  the  core  of  the  day-to-day  data  entry  needs.  This  includes  the 
data  generated  during  voyages  and  the  information  from  vessel  surveys.  Automated  procedures 
have  to  be  developed  that  limit  the  amount  of  data  input. 

The  use  of  plate  thickness  gauging  devices,  that  electronically  store  both  the  gauging  location 
and  the  measured  plate  thickness,  can  greatly  reduce  the  amount  of  data  input  for  corrosion 
surveys.  However,  research  is  needed  to  derive  a  location  definition  that  makes  it  possible  to 
clearly  (and  with  sufficient  accuracy)  identify  the  gauging  locations. 

6.4.4  Queries,  Reports 
6.4.4. 1  Purpose 

Although  data  storage  is  the  primary  function  of  a  database,  only  the  subsequent  analysis  and 
presentation  of  this  data  makes  it  necessary  to  store  data  in  an  electronic  form.  A  database 
management  system  has  to  provide  convenient  and  accurate  reporting  functions  that  are  custom 
tailored  to  the  specific  needs  of  the  database  users. 

It  has  to  be  possible  to  define  database  queries  that  can  evaluate  any  possible  combination  of 
different  database  relations.  In  addition,  standardized  queries  have  to  be  provided  that  summarize 
and  evaluate  the  most  common  information.  These  queries  can  then  form  the  basis  for  various 
standard  reports  that  are  based  on  the  database  analysis.  The  most  prominent  report  resulting 
from  the  SSIIS  database  will  be  the  CAIP  report  for  a  vessel.  A  dedicated  function  has  to  be 
provided  by  the  database  management  system,  that  automatically  creates  the  core  of  a  CAIP 
report,  which  only  needs  a  few  individual  comments  and  summaries. 
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6.4.4. 2  Customized  Queries 

The  SSIIS  database  system  contains  a  large  amount  of  information  about  all  aspects  of  tanker 
configurations  and  operations.  Although  standardized  queries  can  be  prepared  for  most  of  the 
basic  information,  the  need  to  evaluate  different  contributing  factors  and  to  study  the  influence  of 
all  possible  parameters  makes  it  necessary  to  provide  the  possibility  to  create  customized  queries 
for  all  of  the  information  contained  in  the  database. 

These  customized  queries  have  to  be  linked  to  a  graphical  output  routine  that  makes  it  possible 
to  quickly  generate  comprehensive  charts  of  the  query  results. 

6.4. 4. 3  CAIP  Reports 

The  U.S.  Coast  Guard  has  implemented  the  requirement  the  preparation  of  Critical  Area  Inspection 
Plan  (CAIP)  reports  for  specific  vessel  classes.  These  reports  are  based  on  the  results  of  structural 
surveys  and  are  intended  to  summarize  the  structural  status  and  failure  history  of  a  vessel. 

One  of  the  main  objectives  of  the  SSIIS  project  is  the  definition  of  a  comprehensive  CAIP 
report  format  based  on  the  evaluation  of  existing  reports.  The  documentation  of  this  process  and 
of  the  resulting  CAIP  report  format  is  included  in  chapter  5. 

The  database  management  system  of  the  SSIIS  database  has  to  provide  a  procedure  that 
facilitates  the  generation  of  a  CAIP  report  for  a  specified  vessel  and  assures  the  uniformity  of  the 
different  CAIP  reports. 

6.4. 4.4  Vessel  Reports 

The  SSIIS  database  is  intended  to  contain  all  relevant  information  that  results  from  the  design, 
construction  and  operation  of  a  vessel.  Standardized  reports  that  summarize  the  vessel  configu¬ 
ration,  the  vessel  construction,  the  survey  and  maintenance  history  and  the  service  history  have 
to  be  included  in  the  DBMS.  The  exact  extent  of  the  standardized  reports  has  to  be  determined 
based  on  the  input  from  operators,  classification  societies  and  other  potential  database  users. 

6. 4.4. 5  Data  Analysis 

Although  customized  queries  and  the  graphical  representation  of  the  query  results  are  important 
tools  for  the  documentation  of  the  database  contents  and  can  help  to  determine  trends,  statistical 
data  analysis  is  another  important  aspect  of  the  DBMS. 

Using  the  results  from  customized  queries,  statistical  analyses  have  to  be  performed  to  deter¬ 
mine  average  values,  standard  deviations  or  simply  additional  data  properties  that  are  based  on  a 
combination  of  other  available  data. 

6.4.4. 6  Inspection  Summaries 

For  each  inspection  that  is  performed,  the  inspection  results  are  included  in  the  SSIIS  database. 
In  order  to  get  an  overvievi^  about  the  inspection  results,  it  is  necessary  to  prepare  inspection 
summaries  that  list  the  most  important  inspection  findings.  Most  of  this  summary  can  be  generated 
automatically.  The  exact  format  of  the  inspection  summaries  has  to  be  determined  based  on 
operator  experience  and  on  the  possible  use  of  the  summaries  for  the  generation  of  the  CAIP 
reports. 

6.5  Conclusions 

In  this  chapter,  the  general  format  of  the  SSIIS  database  system  has  been  outlined.  The  sys¬ 
tem  consists  of  the  actual  database  structure  and  a  database  management  system  (DBMS)  that 
performs  the  administrative,  data  entry  and  reporting  functions  using  the  database  structure. 
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The  main  components  of  the  database  structure  have  been  clearly  defined.  For  each  module 
the  necessary  data  relations  are  summarized  and  listed  in  an  itemized  form.  Necessary  additional 

research  is  clearly  defined.  \  r  r  i.-  i 

The  different  components  of  the  DBMS  are  outlined.  The  actual  development  of  a  functional 

DBMS  depends  strongly  on  the  development  software  and  the  actual  database  system  that  will 
be  used.  A  simplified  version  of  the  DBMS  will  be  developed  as  part  of  the  SSIIS  prototype 
development,  documented  in  chapter  7. 
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Figure  6.1:  Database  Overview 
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Figure  6.3:  Design  Module 
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Figure  6.4;  Construction  Module 


111 


Frame  Loc 


Tank  Geometry 


Anodes 

Coating 

Figure  6.5:  Modification  Module 


Figure  6.6;  Inspection  Module 
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Figure  6.7:  Detail  Sub-Module 
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Figure  6.8:  Maintenance  Module 
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Figure  6.9:  Repair  Module 
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Figure  6.10:  Operations  Module 
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Figure  6.11:  Monitoring  Module 
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Figure  6.12:  Database  Management  System 
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Chapter  7 


Prototype  Development 


7.1  Introduction 

The  third  main  objective  of  the  SSIIS  project  consists  of  the  development  of  a  prototype  database 
system  that  demonstrates  possible  applications  for  the  SSIIS  database  structure.  This  includes  a 
functional  user  interface,  a  coherent  data  structure  that  shows  the  connectivity  of  the  vessel  and 
survey  data  and  a  reporting  module  that  can  generate  standard  reports  and  also  allows  it  to  create 
customized  queries. 

The  main  reason  that  has  led  to  the  development  of  the  SSIIS  database  structure  was  the  need 
for  a  unified  methodology  for  the  preparation  of  Critical  Area  Inspection  Plan  (CAIP)  reports. 
The  developed  database  system  has  to  be  able  to  produce  CAIP  reports  based  on  the  available 
vessel  information  and  survey  results.  The  application  prototype  is  therefore  largely  focused  on 
the  CAIP  report  generating  module. 

Based  on  the  data  requirements  for  the  CAIP  reports  and  on  the  core  data  necessary  for 
the  general  representation  of  the  vessel  structure,  a  reduced  data  structure  is  implemented  using 
a  relational  database  concept.  Using  this  implemented  data  structure,  a  database  management 
system  is  developed  that  documents  all  the  main  features  of  an  effective  DBMS  for  the  SSIIS 
vessel  database  system.  Included  in  the  DBMS  is  a  function  for  the  generation  of  CAIP  reports. 

7.2  CAIP  Reporting  Requirements 

Based  on  the  CAIP  report  format  developed  in  chapter  5  a  CAIP  report  function  is  implemented  in 
the  prototype  application.  This  function  is  intended  to  document  the  ability  of  the  SSIIS  database 
system  to  generate  functional  and  effective  CAIP  reports  with  a  minimum  of  user  input. 

Some  of  the  desired  functionality  can  not  be  implemented  in  the  limited  prototype  application 
since  no  graphical  representations  of  the  structural  geometry  is  provided. 

The  CAIP  report  is  structured  into  the  following  sections; 

•  Executive  Summary:  The  executive  summary  uses  some  information  from  the  database 
in  combination  with  user  input  to  provide  a  concise  and  up-to-date  summary. 

•  Vessel  Summary;  The  vessel  summary  is  completely  based  on  database  information.  The 
general  arrangement  plan  is  supplied  as  a  drawing  instead  of  being  based  on  tank  and  hull 
information  directly. 

•  Failure  History:  The  failure  history  is  based  entirely  on  the  database  information.  It 
includes  failure  distributions  over  the  shiplength  and  additional  summaries.  No  graphical 
representations  of  failures  are  included. 
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•  Critical  Inspection  Area  Summary:  The  critical  inspection  area  summary  is  limited 
due  to  the  missing  graphical  failure  information.  The  different  areas  are  summarized  and 
the  available  failure  information  is  listed. 

•  Coating  History:  Since  the  modifications  module  is  not  implemented,  the  coating  history 
is  only  provided  as  an  example  and  is  not  based  on  database  information. 

•  CAIP  Update  :  The  CAIP  update  information  is  based  on  company  planning  and  is  not 
available  in  the  SSIIS  database  at  the  present  time.  Editing  capabilities  are  therefore  pro¬ 
vided  to  enter  the  planned  CAIP  updating  information 

7.3  Prototype  Data  Structure 

The  database  structure  has  been  developed  to  include  all  ship  specific  information  and  the  corrosion 
and  crack  related  survey  results.  The  format  has  been  developed  based  on  the  database  structure 
shown  in  Fig.  (6.2)  and  on  the  CAIP  reporting  requirements  outlined  in  section  7.2. 

The  database  structure  consists  of  several  relations.  The  theory  of  relational  databases  requires 
that  each  record  in  a  relation  is  uniquely  defined  by  a  key.  This  key  can  consist  of  a  combination 
of  data  items,  e.g.  the  key  of  the  Tank  relation  is  defined  by  the  Class _ID,  the  Tank-#  and  the 
TcinkXoc. 

In  the  following  sections  each  relation  is  described  in  detail  including  the  key,  the  data  items 
in  the  body  of  the  relation  and  the  links  to  other  relations.  The  sections  are  named  according  to 
the  relation  name.  Each  data  item  that  has  a  #  in  the  first  column  is  linked  to  an  other  relation. 

7.3.1  Relation:  VESSEL 

The  relation  VESSEL  contains  the  ship  specific  information  for  the  ships  entered  in  the  database. 
This  includes  only  information  that  is  only  relevant  for  one  ship.  All  information  that  is  identical 
for  a  class  of  ships  is  contained  in  the  CLASS  relation. 


VESSEL 

VesseLID 

Num 

4.0 

Class-ID 

Num 

4.0 

Name 

Char 

30 

# 

Owner 

Char 

20 

# 

Operator 

Char 

20 

# 

Classification 

Char 

4 

Delivery 

Date 

8 

# 

Shipyard 

Char 

20 

HulLNo 

Num 

5.0 

Key:  The  key  of  this  relation  is  the  Vessel_ID.  This  is  simply  a  four  digit  number.  Each  entry  in 
the  VESSEL  relation  has  to  have  a  unique  number. 


Links:  Four  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

Class_ID  - 

CLASS 

Classification  - 

-  CLASSIF 

Shipyard  - 

-  YARD 

Owner  - 

-  COMPANY 

Operator  - 

-  COMPANY 
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7.3.2  Relation:  CLASSIF 

The  relation  CLASSIF  contains  the  information  regarding  the  classification  society  that  has 
classified  the  ship.  Using  this  relation  instead  of  entering  the  name  of  the  classification  society 
directly,  reduces  the  amount  of  input  and  also  avoids  the  possibility  of  an  input  error  by  misspelling 
the  name.  This  relation  contains  of  a  character  code  word,  the  name  of  the  classification  society 
and  the  country. 


CLASSIF 

ClassiOD 

Char 

4 

Name 

Char 

20 

Country 

Char 

20 

Key:  The  key  of  this  relation  is  the  Classif  JD.  This  key  is  a  four  character  code  word.  This  has 
been  chosen  since  most  classification  societies  are  known  under  an  abbreviated  form  of  their  name. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.3  Relation:  COMPANY 

The  relation  COMPANY  contains  the  information  regarding  the  company  that  owns  and/or 
operates  a  vessel.  Using  this  relation  instead  of  entering  the  name  of  the  owner/operator  directly, 
reduces  the  amount  of  input  and  also  avoids  the  possibility  of  an  input  error  by  misspelling  the 
name.  This  relation  contains  of  a  character  code  word,  the  name  of  the  company  and  the  address. 


CLASSIF 

Company  JD 

Num 

4 

Name 

Char 

20 

Address 

Char 

40 

Key:  The  key  of  this  relation  is  the  Company -ID.  This  is  a  integer  value  that  has  to  be  unique  for 
each  company. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.4  Relation:  YARD 

The  relation  YARD  contains  the  information  regarding  the  shipyard  that  built  a  vessel.  Using 
this  relation  instead  of  entering  the  name  of  the  shipyard  directly,  reduces  the  amount  of  input 
and  also  avoids  the  possibility  of  an  input  error  by  misspelling  the  name.  This  relation  contains  of 
a  character  code  word,  the  name  of  the  shipyard  and  the  address. 


YARD 

YardJD 

Num 

4 

Name 

Char 

20 

Address 

Char 

40 

Key:  The  key  of  this  relation  is  the  Yard_ID.  This  is  a  integer  value  that  has  to  be  unique  for  each 
shipyard. 
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Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.5  Relation:  CLASS 

The  relation  CLASS  contains  the  information  that  is  specific  for  a  class  of  vessels.  This  includes 
the  main  dimensions,  the  construction  type  and  the  propulsion  system. 


CLASS 

ClassJD 

Num 

4.0 

Class-Name 

Num 

4.0 

LOA 

Num 

4.3 

LBP 

Num 

4.3 

Depth 

Num 

3.3 

Beam 

Num 

3.3 

Draft 

Num 

3.3 

SummerJDWT 

Num 

7.0 

Double-Bot 

Log 

1 

Double-Side 

Log 

1 

LBhd-Pos 

Num 

2.3 

Turbines 

Log 

1 

Cylinders 

Num 

2.0 

No-Blades 

Num 

2.0 

Screw-Rpm 

Num 

3.0 

Speed-Load 

Num 

2.2 

Speed-Ball 

Num 

2.2 

Thrusters 

Log 

1 

Bilge-K 

Log 

1 

Key:  The  key  of  this  relation  is  the  Class  JD.  This  is  a  integer  value  that  has  to  be  unique  for 
each  class. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.6  Relation:  TANK 

The  relation  TANK  contains  information  for  each  tank  for  each  ship.  This  information  includes 
size,  location,  contents  and  tank  washing.  This  information  is  very  detailed,  in  order  to  be  able  to 
include  all  relevant  information  for  a  vessel. 

The  tank  information  is  class  specific.  Tanks  for  one  class  of  ships  are  usually  identified  by 
a  number  and  the  location  with  respect  to  the  width  of  the  ship  (Port,  Center  and  Starboard). 
Therefore  the  key  for  the  TANK  relation  consists  of  three  items,  Class  JD,  Tank-#  and  Width-Loc. 
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TANK 

ClassJD 

Num 

4.0 

■ 

Tank-# 

Num 

2.0 

■ 

Width-Loc 

Char 

1 

Length 

Num 

4.3 

Beam 

Num 

3.3 

Depth 

Num 

3.3 

Capacity 

Num 

6.1 

# 

Frame-aft 

Num 

3.0 

# 

Frame-for 

Num 

3.0 

Type-ID 

Char 

1 

# 

Corr-Protect 

Char 

2 

Cargo-Heated 

Char 

1 

IGS-Sulphur 

Num 

2.1 

Tank-Washing 

Char 

1 

Wash-Medium 

Char 

1 

Wash-Freq 

Num 

2.0 

Key:  This  key  of  this  relation  consists  of  three  data  items,  the  Class_ID,  TankJt  and  Width-Loc. 
The  combination  of  these  three  items  has  to  be  unique  for  each  record. 

Links:  Four  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

Frame_Aft  - 

LENGTH 

Frame_For  - 

LENGTH 

TypeJD  - 

-  TANKTYPE 

Corr-Protect  - 

-  CORR-PRO 

7.3.7  Relation:  TANKTYPE 

The  relation  TANKTTYPE  contains  the  information  regarding  the  type  of  tank.  This  relation 
allows  it  to  use  a  code  word  for  the  type  of  tank  and  link  it  to  a  description.  It  also  ensure  that 
no  invalid  tank  type  can  be  entered. 


TANKTYPE 

TypeJD 

Char 

1 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  Type_ID.  This  key  is  a  one  character  code  word. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.8  Relation:  CORR_PRO 

The  relation  CORR_PRO  contains  the  information  regarding  the  corrosion  protection  system. 
The  code  word  for  the  corrosion  protection  system  can  be  linked  to  a  description. 
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CORR_PRO 

Corr-Pro_ID 

Char 

1 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  Corr_Pro-ID.  This  key  is  a  one  character  code  word. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.9  Relation:  SIDE 

The  relation  SIDE  contains  the  information  regarding  the  width  location  within  the  ve,ssel.  The 
code  word  of  the  Width_Loc  is  assumed  to  take  five  different  values,  which  allows  it  to  divide  the 
width  of  the  ship  in  five  parts.  These  five  divisions  can  be  related  to  the  tank  location  (port,  center 
or  starboard)  and  the  ship  side  (port  or  starboard). 


SIDE 

Width-Loc 

Char 

2 

Tank-Loc 

Char 

1 

Side 

Char 

1 

Key:  The  key  of  this  relation  is  the  WidthXoc.  This  key  is  a  two  character  code  word. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.10  Relation:  LENGTH 

The  relation  LENGTH  contains  the  information  regarding  the  longitudinal  positions  for  each  class 
of  ships.  This  relation  links  the  frame  numbers  to  the  distance  from  the  Aft  perpendicular,  which 
allows  it  enter  information  according  to  the  frame  number  and  still  be  able  to  obtain  the  distance 
from  the  aft  perpendicular.  This  can  be  used  to  non-dimensionalize  the  longitudinal  position. 
This  relation  requires  a  key  that  consists  of  two  data  items,  the  ClassTD  and  the  FrameJt. 


LENGTH 

ClassJD 

Num 

4.0 

Frame# 

Num 

3.0 

Dist_AP 

Char 

4.3 

Key:  The  key  of  this  relation  is  the  Class-ID  and  the  Frame#.  The  combination  of  these  two  data 
items  has  to  be  unique  for  each  record. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.11  Relation:  INSPECTION 

The  relation  INSPECTION  contains  the  information  regarding  the  inspection.  Each  entry  spec¬ 
ifies  one  inspection  for  a  particular  ship.  Therefore  two  items  form  the  key  for  this  relation. 
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The  INSPECTION  relation  contains  for  each  inspection  information  about  the  date,  location 
company  and  technicians. 


INSPECTION 

VesseLID 

Num 

4.0 

Inspection-ID 

Char 

5 

St  art -Date 

Date 

8 

End-Date 

Date 

8 

# 

Location 

Char 

20 

# 

Company 

Char 

20 

Ut-Techl 

Char 

20 

Ut-Tech2 

Char 

20 

Ut_Equip 

Char 

20 

Key:  This  key  of  this  relation  consists  of  two  data  items,  the  Vessel-ID  and  the  InspectionJID. 
This  means  that  the  combination  of  the  VesseLID  and  the  Inspection.ID  has  to  be  unique  for  each 
record. 

Links:  Two  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

T 

PORT 

l^ocAtion 

TTvrcr>  r'r»A,TT>A  ivrv 

7.3.12  Relation:  INSP.COMPANY 

The  relation  INSP_COMPANY  contains  the  information  regarding  the  company  that  performed 
the  inspection.  Using  this  relation  instead  of  entering  the  name  of  the  inspection  company  directly, 
reduces  the  amount  of  input  and  also  avoids  the  possibility  of  an  input  error  by  misspelling  the 
name.  This  relation  contains  of  a  character  code  word,  the  name  of  the  company  and  the  address. 


CLASSIF 

Company  JD 

Num 

4 

Name 

Char 

20 

Address 

Char 

40 

Key:  The  key  of  this  relation  is  the  Company  JCD.  This  is  a  integer  value  that  has  to  be  unique  for 
each  company. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.13  Relation:  CRITICAL-AREA 

The  relation  CRITICAL-AREA  contains  the  information  regarding  the  defined  critical  inspec¬ 
tion  areas  for  a  vessel.  The  relation  includes  the  vessel,  class  information  and  tank  information  for 
each  critical  inspection  area. 
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CRITAREA 

CritArea 

Num 

10.0 

# 

Vessel-ID 

Num 

4.0 

# 

ClassJD 

Num 

4.0 

# 

Tank# 

Num 

2.0 

# 

Tank-Pos 

Char 

1 

Description 

Char 

60 

Key:  The  key  of  this  relation  is  the  CritArea,  Vessel-ID,  Class_ID,  Tank#  and  Tamk-Pos. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.14  Relation:  CORROSION 

The  relation  CORROSION  contains  the  information  for  all  corrosion  wastage  incidents.  This 
includes  the  detailed  description  of  the  location,  the  corrosion  type  and  the  plate  thickness  infor¬ 
mation. 

As  can  be  seen  in  the  following  table,  a  large  portion  of  the  data  items  in  the  CORROSION 
relation  are  linked  to  other  relations.  Only  the  more  or  less  arbitrary  information  regarding  the 
location  and  the  plate  thickness  are  input  directly. 


CORROSION 

Corr-Count 

Num 

10.0 

# 

Vessel-ID 

Num 

4.0 

# 

Tank# 

Num 

2.0 

# 

Tank-Pos 

Char 

1 

# 

Width-Loc 

Char 

2 

# 

Frame# 

Num 

3.0 

Height 

Num 

2.3 

Width 

Num 

2.3 

# 

Inspection-ID 

Char 

5 

# 

Corr-Type 

Char 

1 

# 

Corr-ID 

Char 

10 

Wastage 

Num 

2.1 

Thick-Orig 

Num 

2.1 

Thick-Rest 

Num 

2.1 

Key:  This  key  of  this  relation  is  the  data  item  Corr -Count.  This  is  an  integer  value  that  has  to 
be  unique  for  each  record. 

Links:  Eight  data  items  are  linked  to  another  relation: 
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Data  Item 

Linked  Relation 

VesselJD  - 

-  VESSEL 

Tank#  - 

-  TANK 

Tank-Pos  - 

-  TANK-POS 

WidthJLoc  - 

-  SIDE 

Frame#  - 

-  LENGTH 

Inspection-ID  - 

-  INSPECTION 

Corr-Type  - 

-  CORRTYPE 

CorrJD  - 

-  CORRID 

7.3.15  Relation:  CORRID 

The  relation  CORRID  contains  the  information  regarding  the  exact  description  of  the  corrosion 
incident.  This  includes  the  description  of  the  structural  detail,  where  the  corrosion  has  been 
measured. 


CORRID 

CorrJD 

Char 

5 

# 

Corr-1 

Char 

3 

# 

Corr.2 

Char 

3 

Key:  The  key  of  this  relation  is  the  CorrJED.  This  key  is  a  ten  character  code  word. 
Links;  Three  data  items  are  linked  to  an  other  relation; 


Data  Item 

Linked  Relation 

A/nr'A>fDTrT>o 

7.3.16  Relation:  CRACK 

The  relation  CRACK  contains  the  information  necessary  for  the  documentation  of  cracks.  This 
includes  the  detailed  description  of  the  location,  the  crack  type  and  some  repair  information. 

As  can  be  seen  in  the  following  table,  a  large  portion  of  the  data  items  in  the  CRACK  relation 
are  linked  to  other  relations.  Only  the  more  or  less  arbitrary  information  regarding  the  location 
and  the  plate  thickness  are  input  directly. 
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Key:  This  key  of  this  relation  is  the  data  item  Crack-Count .  This  is  an  integer  value  that  has  to 
be  unique  for  each  record. 

Links:  Eleven  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

Vessel-ID  - 

VESSEL 

Tank#  - 

TANK 

Width-Loc  - 

-  SIDE 

Frame#  - 

-  LENGTH 

Inspection-ID  - 

-  INSPECTION 

CrackJD  - 

-  CRACKTYPE 

Class  - 

-  CLASS 

Steel  - 

STEEL 

Rep-Type  - 

-  REP -TYPE 

CauseJD  - 

-  CAUSE 

Links:  Six  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

A^ir.A/TRir.T?i 

L/*!  ctLiv-1 

A/rir.lV/TTlF.RO 

dCK— Z 

A  f  1 

TVyTF.A/TRlT.l^  1 

AL_1 

A  +  D 

AX—l 

ri _ L 

CT'A 

7.3.18  Relation:  TANK_POS 

The  relation  TANK_POS  contains  the  information  regarding  the  horizontal  position  in  the  tank. 
The  corrosion  database  format  divides  each  tank  into  three  zones,  forward  ,  middle,  aft.  This 
relation  contains  the  code  word  for  the  position  and  a  description. 


TANK_POS 

Tank_PosJD 

Char 

1 

Description 

Char 

15 

Key:  The  key  of  this  relation  is  the  Tank-Pos_ID.  This  key  is  a  one  character  code  word. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.19  Relation:  CORRTYPE 

The  relation  CORRTYPE  contains  the  information  regarding  the  type  of  corrosion.  In  the 
present  state  of  the  corrosion  database  format  three  types  of  corrosion  are  considered  (general 
corrosion,  pitting,  grooving).  This  relation  contains  the  code  word  for  the  corrosion  type  and  a 
description. 


CORRTYPE 

■ 

CorrTypeJD 

Char 

1 

■ 

Description 

Char 

15 

Key:  The  key  of  this  relation  is  the  CorrTypeJED.  This  key  is  a  one  character  code  word. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.20  Relation:  DETAIL 

The  relation  DETAIL  contains  the  information  regarding  the  structural  configuration  for  a  detail. 
In  the  simplified  implementation  of  the  prototype  development  this  relation  replaces  the  sub- 
module  Detail  that  has  been  defined  in  chapter  6.  The  detail  is  defined  with  a  text  based  definition. 


DETAIL 

DetailJD 

Char 

3 

Description 

Char 

600 

126 


Key:  The  key  of  this  relation  is  the  Detail  JD.  This  key  is  an  integer  value. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.21  Relation:  START 

The  relation  START  contains  the  information  regarding  the  location  of  the  start  of  a  crack.  This 
information  is  necessary  for  a  detailed  analysis  of  failure  probabilities  and  allows  it  to  clearly 
distinguish  cracks  in  the  same  type  of  detail,  but  starting  at  different  points. 


START 

StartJD 

Char 

3 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  Start  JED.  This  key  is  a  three  character  code  word. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.22  Relation:  CRACK_CL 

The  relation  CRACK_CL  contains  the  information  regarding  the  class  of  a  crack.  The  definition 
is  based  on  the  system  of  crack  classes  established  by  the  U.S.  Coast  Guard. 


CRACK-CL 

H 

Crack.CUD 

Num 

1.0 

1 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  Crack-CIJD.  This  key  is  a  one  digit  integer. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.23  Relation:  STEEL 

The  relation  STEEL  contains  the  information  regarding  the  steel  type  of  a  detail.  This  definition 
is  intended  to  allow  the  distinction  between  mild  steel  and  high  tensile  steel  (HTS). 


STEEL 

Steel-ID 

Char 

3 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  SteeUD.  This  key  is  a  three  character  code  word. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 
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7.3.24  Relation:  REPAIR 

The  relation  REPAIR  contains  the  information  regarding  the  type  of  repair  that  has  been  used. 
This  can  include  e.g.  rewelding,  redesign,  etc.  . 


REPAIR 

Rep-ID 

Char 

3 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  Rep -ID.  This  key  is  an  integer  value. 
Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.3.25  Relation:  CAUSE 

The  relation  CAUSE  contains  the  information  regarding  the  cause  for  a  crack.  This  cause  can  be 
a  combination  of  up  to  three  contributors. 


CAUSE 

Cause-ID 

Char 

6 

lO 

Primary 

Char 

2 

O 

Secondary 

Char 

2 

11 

Tertiary 

Char 

2 

Key:  The  key  of  this  relation  is  the  Cause-ID.  This  key  is  a  three  character  code  word. 


Links:  Three  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

Ti-  r^ATTCiT.  riiTiir 

CATTSF  r>EF 

n  A  TTcir  nirir 

7.3.26  Relation:  CAUSE_DEF 

The  relation  CAUSEJDEF  contains  the  information  regarding  the  possible  contributors  for  the 
cause  of  a  crack.  This  can  include  fatigue,  corrosion,  damage,  etc.  . 


CAUSEJDEF 

Cause-Key 

Char 

2 

Description 

Char 

20 

Key:  The  key  of  this  relation  is  the  CauseJCey.  This  key  is  a  two  character  code  word. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 
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7.3.27  Relation:  LEG 


The  relation  LEG  contains  the  information  regarding  to  the  individual  legs  on  a  voyage  for  a 
vessel.  For  each  leg,  the  arrival  and  departure  port,  the  cargo,  the  loading  conditions  and  the  crew 
are  listed. 


Key:  The  key  of  this  relation  is  the  Leg-ID,  the  Vessel-ID  and  the  Class_ID.  The  Leg_ID  is  an 
integer  value. 

Links:  Three  data  items  are  linked  to  an  other  relation: 


Data  Item 

Linked  Relation 

Departure-Port  - 

-  PORTS 

Destination-Port  - 

PORTS 

CargoJD 

-  CARGO 

7.3.28  Relation:  PORTS 

The  relation  PORTS  contains  the  information  regarding  the  different  ports  on  a  vessel  route.  This 
relation  is  again  particularly  useful  since  only  a  very  limited  number  of  ports  exist. 


PORTS 


Key:  The  key  of  this  relation  is  the  PortsJCD.  This  key  is  an  integer  value. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 
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7.3.29  Relation:  CARGO 


The  relation  CARGO  contains  the  information  regarding  the  type  of  cargo  that  is  transported. 
This  relation  is  again  particularly  useful  since  only  a  very  limited  number  of  distinct  possibilities 
are  available  as  cargo. 


CARGO 

CargoJD 

Char 

1 

II 

Description 

Char 

15 

1 

CargoJSulphur 

Num 

2.1 

I 

Cargo-Water 

Num 

2.1 

1 

Cargo-Waxy 

Char 

1 

Key:  The  key  of  this  relation  is  the  Cargo_ID.  This  key  is  a  one  character  code  word. 


Links:  None  of  the  data  items  is  linked  to  another  relation. 


7.4  Implementation 

7.4.1  System  Requirements 

The  SSIIS  database  has  been  implemented  based  on  the  data  structure  documented  in  section  7.3 
using  a  commercially  available  database  development  software,  Microsoft  Access  1.1  ^  .  The 
software  requires  an  IBM  compatible  PC  with  a  minimum  of  2MB  of  RAM  (4MB  recommended) 
running  Microsoft  Windows  3.1. 

Usage  information  for  Microsoft  Access  1 . 1  can  be  found  in  [26],  [30].  A  language  reference 
is  contained  in  [25].  Information  about  programming  in  Microsoft  Access  Basic  is  contained  in 
[33]. 

7.4.2  General  Design 

The  implementation  of  the  working  model  is  to  a  large  extent  based  on  the  use  of  Forms,  Queries, 
Tables  and  Macros.  The  datastructure  has  been  implemented  using  the  table  definition  procedures 
of  Access.  Data  relations  have  been  established  between  the  tables  that  ensure  referential  integrity. 

With  the  datastructure  implemented,  the  database  management  has  been  developed  based  on 
the  requirements  outlined  in  section  6.4  This  includes  administration,  data  entry  and  reporting  / 
query  capabilities.  The  database  management  system  uses  a  menu  based  structure  to  implement 
these  capabilities. 

Some  advanced  features  are  not  completely  implemented.  The  corresponding  menu  items 
are  provided  to  document  the  general  setup  of  the  databeise  management  system.  A  massage  is 
displayed  that  states  that  the  function  is  not  implemented. 

The  database  is  started  by  selecting  the  button  on  the  Windows  desktop.  A  main  data  screen 
is  displayed  that  contains  five  different  menu  items.  The  main  data  screen  is  shown  in  Fig.  (7.1). 
The  following  five  menu  items  are  available: 

•  Administration:  This  leads  to  a  menu  that  contains  all  the  administrative  functions. 

•  Data  Entry:  All  data  entry  functions  are  accessed  from  this  menu  item. 

^Microsoft  Access  1.1,  Relational  Database  Management  System  for  Windows,  Microsoft  Corporation, 
1992 
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•  Report  /  Query;  All  reporting  and  query  functions  are  in  the  menu  that  is  displayed  if 
this  item  is  selected. 

•  Database  Window:  This  item  allows  it  to  use  the  advanced  features  of  Access. 

•  Exit:  The  database  session  is  terminated. 

The  software  provides  complete  data  entry  capabilities.  Data  for  all  tables  can  be  entered.  In 
addition,  general  reporting  capabilities  are  outlined  including  the  ability  to  generate  CAIP  reports 
for  individual  vessels. 

7.4.3  Administration 

As  outlined  in  section  6.4  the  SSIIS  database  management  system  has  to  have  administrative  func¬ 
tions  that  allow  it  to  change  system  settings,  manage  user  privileges  and  maintain  data  integrity. 
These  functions  are  grouped  in  a  selection  screen  that  is  accessed  by  selecting  the  Administration 
button  on  the  Main  screen.  The  administration  screen  is  shown  in  Fig.  (7.2). 

7.4.4  Data  Entry 

Data  entry  screens  have  been  designed  for  all  tables.  The  data  entry  is  organized  in  a  screen 
with  4  different  menu  items,  which  is  accessed  from  the  main  menu  by  selecting  (double-clicking) 
the  Enter  Data  button.  The  data  entry  selection  screen  is  shown  in  Fig.  (7.3).  It  contains  the 
following  four  menu  items: 

•  System  Data:  This  identifies  data  that  is  necessary  background  information  that  has  to  be 
available  in  the  database  to  ensure  data  integrity.  The  selection  screen  for  the  entry  of  the 
system  data  is  shown  in  Fig.  (7.4).  The  individual  data  entry  screens  for  the  system  data 
are  described  in  appendix  E.l. 

•  Vessel;  All  vessel  related  data  is  input  in  this  menu.  This  includes  the  vessel,  class,  tank 
data.  The  selection  screen  for  the  entry  of  the  vessel  data  is  shown  in  Fig.  (7.5).  The 
individual  data  entry  screens  for  the  vessel  data  are  described  in  appendix  E.2. 

•  Inspection:  All  inspection  data  entry  is  accessed  from  this  menu  item.  This  includes  the 
actual  inspection  location,  date  and  company.  In  addition,  crack  and  corrosion  survey  results 
entry  screens  can  be  accessed  from  this  menu  screen.  The  selection  screen  for  the  entry  of  the 
inspection  data  is  shown  in  Fig.  (7.6).  The  individual  data  entry  screens  for  the  inspection 
data  are  described  in  appendix  E.3. 

•  Operations:  The  information  regarding  vessel  operations  can  be  entered  based  on  this 
menu  item.  This  includes  the  individual  voyage  legs,  the  monitoring  information  and  the 
ports.  The  selection  screen  for  the  entry  of  the  operations  data  is  shown  in  Fig.  (7.7).  The 
individual  data  entry  screens  for  the  operations  data  are  described  in  appendix  E.4. 

7.4.5  Reports  /  Queries 

The  third  selection  on  the  Main  screen  leads  to  the  menu  for  the  different  reporting  functions. 
This  menu  is  shown  in  Fig.  (7.8).  It  contains  the  following  four  menu  items: 

•  Vessel  Summary:  Based  on  the  selection  of  a  vessel  from  the  list  of  available  vessels,  a 
summary  of  this  vessel  is  provided,  including  general  arrangement,  vessel  particulars  and  a 
tank  summary. 

•  Fracture  Summary:  For  a  selected  vessel  and  inspection  date,  a  summary  of  fractures  is 
provided.  This  includes  the  distribution  of  fractures  over  the  shiplength,  a  summary  of  the 
most  frequent  crack  locations  and  a  summary  of  the  repair  status. 
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•  Corrosion  Summary:  The  corrosion  summary  contains  a  three-dimensional  view  of  the 
vessel  with  colour-coded  gauging  location  identifying  the  relative  wastage. 

•  CAIP  Report:  The  CAIP  report  for  a  selected  vessel  follows  the  format  outlined  in  chap¬ 
ter  5.  It  consists  of  an  executive  summary,  a  vessel  summary,  a  fracture  summary  for  critical 
inspection  areas  and  a  coating  summary. 

7.4.6  Summary 

A  prototype  application  of  the  SSIIS  database  system  has  been  developed  and  implemented  based 
on  the  data  structure  and  database  management  requirements  that  are  outlined  in  chapter  6. 

The  overall  structure  of  the  SSIIS  database  is  clearly  defined  including  all  necessary  database 
management  components.  Data  entry  screens  and  procedures  are  provided  for  all  tables  that  are 
included  in  the  database. 

The  administrative  functions  are  indicated,  but  not  effectively  implemented  since  they  are  only 
necessary  for  a  commercial,  multi-user  application.  The  selection  screen  for  the  administrative 
functions  identifies  the  different  functional  requirements. 

Four  different  reporting  functions  are  indicated  in  the  reporting  selection  screen.  This  includes 
vessel,  crack,  corrosion  and  CAIP  reporting  functions.  These  reporting  functions  are  partially  im¬ 
plemented  to  document  the  capabilities  of  the  SSIIS  database  system  with  respect  to  the  generation 
of  CAIP  reports. 

The  developed  application  prototype  can  be  used  as  a  starting  point  for  a  commercial  develop¬ 
ment  or  a  more  thorough  implementation  as  part  of  a  follow-up  university  project.  Most  functions 
have  to  be  improved  in  order  to  make  them  more  robust  and  to  prohibit  data  entry  errors. 
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Figure  7.1:  Main  Database  Screen 


Figure  7.2:  Administration  Selection  Screen 
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Figure  7.5:  Vessel  Data  Entry  Screen 
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Figure  7.6:  Inspection  Data  Entry  Screen 


Figure  7.7:  Operations  Data  Entry  Screen 


Figure  7.8:  Reports  Menu  Screen 
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Chapter  8 

Conclusion  and 
Recommendat  ions 


8.1  Conclusions 

Within  the  SSIIS  project  a  general  database  system  for  oil  tankers  has  been  developed.  The 
development  was  based  on  a  detailed  review  of  existing  databeise  systems,  a  definition  of  reporting 
requirements  for  Critical  Area  Inspection  Plan  (CAIP)  reports  and  a  survey  of  the  data  needs  of 
existing  vessel  analysis  software. 

The  analysis  of  existing  database  software  includes  the  most  important  software  applications 
that  are  currently  used.  Sufficient  background  information  about  the  general  design  of  a  vessel 
database  has  been  obtained  from  the  analysis  of  the  existing  software  systems.  Several  of  the 
existing  systems  can  be  adapted  to  produce  CAIP  reports  that  meet  the  format  requirements 
developed  in  chapter  5. 

Existing  CAIP  reports  have  been  reviewed  with  the  intent  to  develop  an  improved  report 
format  that  combines  a  high  information  contents  with  a  simplified,  graphical  representation  of 
failure  trends.  The  review  of  the  existing  CAIP  reports  has  shown  several  different  report  formats 
that  varied  widely  in  format  and  data  contents.  Based  on  this  review,  a  new  report  format  heis 
been  developed  with  the  aim  to  unify  the  CAIP  reports  and  make  them  more  usable  for  vessel 
inspectors  and  operators. 

The  resulting  format  definition  is  used  in  the  development  of  the  application  prototype  and  will 
result  in  a  more  concise  CAIP  report  that  can  be  used  to  quickly  identify  the  vessel’s  structural 
configuration  and  the  history  of  structural  failures. 

The  general  format  for  the  SSIIS  database  hcis  been  defined.  This  format  consists  of  the  actual 
database  structure  and  a  database  management  system.  All  components  of  the  datastructure  have 
been  defined,  identifying  the  purpose  and  the  data  contents.  For  the  components  necessary  for  the 
generation  of  the  CAIP  reports,  the  data  contents  h2is  been  defined  in  more  detail. 

The  database  management  system  is  outlined  including  the  definition  of  all  the  functional 
requirements  necessary  for  a  general  vessel  databaise.  These  definitions  can  be  used  as  a  starting 
point  for  the  development  of  a  commercial  application. 

The  developed  application  prototype  is  intended  to  show  the  general  functionality  of  a  vessel 
database  system.  The  preliminary  data  structure  has  been  defined  with  the  main  emphasis  on  the 
structural  and  inspection  data  that  is  necessary  for  the  generation  of  CAIP  reports.  The  database 
management  system  is  implemented  to  show  the  general  structure.  Only  the  functions  necessary 
for  data  input  and  the  generation  of  CAIP  reports  are  implemented. 
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8.2  Recommendation  for  Future  Development 

Additional  research  is  needed  to  further  determine  the  data  needs  of  analysis  software.  This  will 
require  the  survey  of  vessel  analysis  software,  particularly  operations  and  management  related 
procedures.  The  resulting  conclusions  with  regard  to  the  data  requirements  of  these  software 
packages  have  to  be  included  in  the  design  of  the  SSIIS  datastructure. 

The  advances  in  vessel  response  monitoring  and  the  resulting  data  have  to  be  studied  further. 
Research  is  necessary  to  determine  a  storage  format  for  monitoring  data  that  does  not  require  a 
large  amount  of  disk  storage  space.  Operator  input  is  necessary  to  identify  the  amount  of  available 
and  necessary  operations  data.  This  includes  economic  information  (accounting  and  payroll), 
routing  and  harbour  data  (waypoint  chains,  harbour  delays)  and  the  desired  amount  of  monitoring 
data. 

In  general,  the  structure  and  the  data  contents  of  all  modules  of  the  data  structure  have  to 
be  improved.  Only  the  Vessel  and  Inspection  module  are  to  a  large  extent  complete.  A  refined 
representation  of  design  modifications  and  repairs  has  to  be  developed  that  makes  it  possible  to 
identify  the  present  condition  of  a  vessel  and  to  document  the  history  of  structural  changes. 

A  detailed  definition  of  the  graphics  format  used  for  the  representation  of  the  structural  con¬ 
figuration  of  a  vessel  has  to  be  developed.  This  includes  the  level  of  detail  and  the  organization 
of  the  structural  drawings.  It  has  to  be  guaranteed  that  the  location  of  defects  in  a  structural 
drawing  matches  the  location  description  in  the  database. 

The  developed  application  prototype  can  be  used  as  a  starting  point  for  a  more  sophisticated,  or 
commercial  application.  The  data  entry  procedures  have  to  be  re-evaluated  to  ensure  data  integrity. 
The  representation  of  the  structural  geometry  has  to  be  improved  to  meet  the  requirements  outlined 
in  chapter  6.  The  reporting  module  has  to  be  improved  to  provide  the  capability  to  generate  fully 
automated  CAIP  reports. 

In  general,  the  present  development  represents  the  starting  point  for  the  development  of  a 
general  Ship  Structural  Integrity  Information  System  (SSIIS).  All  necessary  components  are  de¬ 
fined.  In  a  second  year  development,  the  different  database  modules  have  to  be  improved  based 
on  extensive  input  from  vessel  operators. 
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Appendix  A 

CATSIR  Database  Structure 


A.l  Vessel  Information  Module 


Vessel  Information 

Vessel  ID 

Units 

Name 

Class  Name 

Owner 

Society 

Registry 

Date 

Builder 

Shipyard 

Hull  No. 

Otficial  No. 

USCG  No. 

Conversion 

Date 

LOA 

LBP 

Depth 

Beam 

DRaft 

Summer  DWT 

Dbl.  Bottom 

Dbl.  Side 

Product 

Crude 

SBT 

IGS  Fitted 

IGS  Gas  Source 

%  Sulphur 

COW 

Heating  Coils 

Engine 

No.  Cyl. 

Screws  No. 

No.  Blades 

Normal  RPM 

Speed  loaded 

Speed  Ballasted 

Bow  Thrust 

Bilge  Keel 

Comments 

1  Vessel  History  | 

Vessel  ID 
From 

Vessel  Owner 
To 

II 

Tank  Information 

Vessel  ID 

Tank  ID 

Description 

Side 

Service 

Length 

Beam 

Depth 

Capacity 

Frame  From 

Frame  To 

Frame  Spacing 

Bottom  Long  Type 

Bottom  Long  Spacing 

Side  Long  Type 

Side  Long  Spacing 

Deck  Long  Type 

Deck  Long  Spacing 

COW  fitted 

COW  on  Top 

COW  on  Bottom 

Coils 

IGS 

Comments 

Drawing 

Log  &  AutoCad^^ 

Vessel  ID 
Frame 
Comments 

Tank  ID 
As-Built 

Drawing  No. 
Description 

Survey  (Inspection) 

Vessel  ID 
Company 
Equipment 
Comment 

Event  ID 
Start  Date 
Technicians 

Location 
End  Date 
Type 

1  Survey  (Inspection) 

Vessel  ID 

Tank  ID 

Drawing 

Event 

No.  Anodes 

Location 

Attachment 

Date 

Manufacturer 

Lot  No. 
Length 
%  Wastage 

Chemistry 

Width 

Condition 

Weight 

Thickness 

Comment 

1  Coating  Data 

Vessel  ID 
Event 
Humidity 
Prod.  No. 
Primer  Type 
Primer  DFT 

1st  Coat  Time 
2nd  Coat.  Date 
Coat.  Type 

Tank  ID 
Manufacturer 
Temperature 
Color 

Primer  Date 
Stripe 

1st  Coat  DFT 
2nd  Coat.  Time 
Comment 

Drawing 

Lot  No. 

Surf.  Prep. 
Breakdown 
Primer  Time 

1st  Coat.  Date 
Total  Area 

2nd  Coat.  DFT 

1  Crack  Survey 

Vessel  ID 
Event 

Side 

Distance 
Length 
Repair  Type 
USCG  Class 

Tank  ID 
Crack  ID 
Zone 

Vt.  Zone 
Prim.  Cause 
Date 

CS  Class 

Drawing 

Frame 

Member 

Type 

Sec.  Cause 
Cost 

Comment 

1  Gauging  -  Wall  Thickness 

Vessel  ID 

Tank  ID 

Drawing 

Event 

Location 

Reading  ID 

Member 

Steel  Type 

Original  Thick. 

Allow.  Waste 

Current  Thick. 

Actual  Waste 

Loss 

Comment 

Surface 

Photo  ID 
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Photographic 

Log 

Vessel  ID 
Frame 

Tank  ID 
Event 

Roll 

Caption 

’itting  Survej 

r 

Vessel  ID 

Tank  ID 

Drawing 

Event 

Rel.  Loc. 

Long.  Stiff.  1 

Long.  Stiff.  2 

Frame  1 

Frame  2 

Pits  Range  1 
Pits  Range  4 

Pits  Range  2 
Comments 

Pits  Range  3 

Renewal  Records 

Vessel  ID 
Event 

Dimensions 

Weigth 

Tank  ID 
Type 
Flat  Bar 

Drawing 
New/ Renew 
Coverage 

A. 2  Tank  Voyage  Log  Module 


Tank  Voyage  Log 

Vessel  ID 

Tank  ID 

Route 

Load  Date 

Discharge  Date 

Load  Port 

Discharge  Port 

Cargo  Type 

Cargo  Level 

Heated 

Temperature 

Spot/Regular 

Ballast  Date 

COW  Date 

Ballast  Origin 

COW  Duration 
COW  Pressure 

Ballast  Level 

COW  Temp 

Wash  Date 

Wash  Type 

Wash  Duration 

Wash  Temp 

Wash  Pressure 

Mucked  Date 
Comment 

No.  Buckets 

Scale 
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Appendix  B 

SID  -  Tree  Structure  for  Detail 
Identification 
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Figure  B.l;  SID  -  SidesheU  Components 
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Figure  B.2:  SID  -  Bottom  Components 


143 


SUPER-  - 

STRUCTURE 

SIDE 


Plating 


-Hor.  — 
Stiffener 


■Ver.  - 

Stiffener 


-Weld - ~~r  Longitudinal 

^Transverse 

-  Penetration/Opening  -i—  Reinforcement 

■-Weld 

■  Flange— - 1— Plate 

■-Weld 

-  Web - r 

■-Weld 

•  Penetration/Opening  -p  Reinforcement 
‘—Plate 

-Flange  - - r  Weld 


■  Window/Door  I — Reinforcement 


Figure  B.3:  SID  -  Super- Structure  Side  Components 
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Figure  B.4:  SID  -  Deck  Components 
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Figure  B.5:  SID  -  Longitudinal  Bulkhead  Components 
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Figure  B.6:  SID  -  Transverse  Bulkhead  Components 
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Figure  B.8:  SID  -  Mast  Components 
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Figure  B.9:  SID  -  Tank  Components 
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Appendix  C 

HECSALV  -  Data  Files 


C.l  Hull  File  (.HUL) 

The  (.HUL)  file  contains  the  hull  offset  data  for  the  HECSALV  software.  All  data  is  stored  in 
metric  units  (M.Tons  -  meters).  All  longitudinal  distances  are  referenced  about  amidships. 


Ship 

name  of  ship 

Unit 

- 

unit  flag  0=metric  l=British 

LRF 

- 

longl  reference  flag  0=amidship  1=AP  2=FP 

LBP 

- 

length  between  perpendiculars 

Beam 

- 

molded  beam 

Depth 

- 

molded  depth 

Rule 

- 

integration  rule  O=parabolic  l=trapezoidal 

Keel 

- 

keel  thickness 

WPMargin 

- 

height  margin  for  computing  waterline  breadth 

NApp  -  no.  of  appended  volumes 

App  -  appendage  allowance 

Appt  -  average  shell  plating  thickness 

NAppHComp  -  no.  of  compartments  appended  to  the  hull 


NSta  -  no.  of  stations  on  the  hull 

NC  -  no.  of  circular  arcs  used  to  define  the  hull 


Sym 

- 

string  indicating  symmetric  stations 

N  Profile 

- 

no.  of  points  on  the  profile  view 

NPlan 

- 

no.  of  points  on  the  plan  view 

NMarginLine 

- 

no.  of  points  on  the  marginline 

OffProfileXi 

- 

Longl  (x)  position  of  Profile  point  i 

OffProfileYi 

- 

vertical  (y)  position  of  Profile  point  i 

OffPlanXi 

- 

Longl  (x)  position  of  Plan  point  i 

OffPlanYi 

- 

vertical  (y)  position  of  Plan  point  i 

MarginLineXi 

- 

Longl  (x)  position  of  profile  point  i 
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MarginLineYi 

MarginLineZi 


vertical  (y)  position  of  profile  point  i 
transverse  (y)  position  of  profile  point  i 


Longl  (x)  position  of  point  i 
no.  of  points  on  station  i 
no.  of  circular  arcs  for  station  i 


CircRij 

CircZ 

CircY 

AppVolDi 

AppVol 

AppVolY 

AppVolX 

AppVolZ 

AppVolV 

AppHCompFNamei 

AppHCompi 

F.SavePlan 

User 

Prj 

Des 

Udate 

Rev 

LPrec 

WPrec 

LOrder 

ShipClass 


vertical  (y)  offset  of  point  j  at  station  i 
transverse  (z)  offset  of  point  j  at  station  i 
pointer  to  the  arc  or  chine  indicator  for  point  j 

radius  for  arc  j  at  station  i 
transverse  (Z)  location  of  center  of  arc  j 
vertical  (y)  location  of  center  of  acr  j 

description  of  appended  volume  i 
appended  volume  i  (positive  or  negative) 
vertical  (Y)  location  of  appended  volume  i 
longl  (X)  location  of  appended  volume  i 
transverse  (Z)  location  of  appended  volume  i 
vertical  extent  of  appended  volume  i 

file  name  for  appended  compartment  i 
flag  for  appended  compartment  i 

flag  if  plan  and  profile  offsets  are  to  be  recomputed 

user  name  or  initials 
project  no. 

Description  of  project 
date  entered 
revision  no. 

length  precision  flag 
weight  precision  flag 
order  of  longl  presentation 

ship  class 


C.2  Compartment  File  (.CMP  .CMA) 

The  (.CMP)  &  (.CMA)  files  contains  the  compartment  offset  data  for  the  HECSALV  software.  All 
data  is  stored  in  metric  units  (M.Tons  -  meters).  All  longitudinal  distances  are  referenced  about 
amidships. 

A  -  compartment  name 

N1  -  location  of  1st  station  within  station  no.  array 

N2  -  location  of  last  station  of  compartment 

N3  -  no.  of  stations  used  to  describe  the  compartment 


no.  of  circular  arcs  used  to  describe  cmpt 
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NP 

- 

no.  of  points  used  to  define  the  compartment 

NPlan 

- 

no.  of  points  on  plan  view  of  compartment 

NProfile 

- 

no.  of  points  on  profile  view  of  compartment 

NDFld 

- 

no.  of  downflooding  points  associated  with  compt 

Rule 

- 

integration  rule 

Comp  Perm 

- 

permeability  of  compartment 

Comp  Perm  Vol 

- 

volume  of  compartment  corrected  for  permeability 

NAppCComp 

- 

no.  of  compartments  appended  to  the  compartment 

CinpVol 

- 

molded  volume  of  compartment 

CinpVCG 

- 

VCG  of  total  compartment 

CinpLCG 

- 

LCG  of  total  compartment 

CinpTCG 

- 

TCG  of  total  compartment 

CinpMaxFS 

- 

slack  free  surface 

CinpFS98 

- 

98%  free  surface 

CinpAftBnd 

- 

aft-most  boundary  of  compartment 

CinpFwdBnd 

- 

fwd-most  boundary  of  compartment 

OfFProfileXi 

- 

longl  (X)  location  of  profile  point  i 

OffProfileYi 

- 

vertical  (Y)  location  of  profile  point  i 

OffPlanXi 

- 

longl  (X)  location  of  plan  point  i 

OfFPlanZi 

- 

transverse  (Z)  location  of  plan  point  i 

OfFDFLDXi 

- 

longl  (X)  location  of  dfld  point  i 

OfFDFLDYi 

- 

vertical  (Y)  location  of  dfld  point  i 

OffDFLDZi 

- 

transverse  (Z)  location  of  dfld  point  i 

Xoffi 

- 

longl  (X)  location  of  station  i 

NPi 

- 

no.  of  points  on  station  i 

NCi 

- 

no.  of  circular  arcs  for  station  i 

Yoffij 

- 

vertical  (y)  offset  of  point  j  at  station  i 

Zoffij 

- 

transverse  (z)  offset  of  point  j  at  station  i 

Circij 

- 

pointer  to  the  arc  or  chine  indicator  for  point  j 

CircRij 

- 

radius  for  arc  j  at  station  i 

CircZ 

- 

transverse  (Z)  location  of  center  of  arc  j 

CircY 

- 

vertical  (y)  location  of  center  of  acr  j 

Sym 

- 

string  indicating  symmetric  stations 

Ship 

- 

name  of  ship 

Class 

- 

ship  class 

LBP 

- 

length  between  perpendiculars 

Beam 

- 

molded  beam 

Depth 

- 

molded  depth 

User 

_ 

user  name  or  initials 
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Prj 

- 

project  no. 

Des 

- 

Description  of  project 

Udate 

- 

date  entered 

Rev 

- 

revision  no. 

Unit 

. 

unit  flag  0=metric  l=British 

LRF 

- 

longl  reference  flag  0=amidship  1=AP  2=FP 

LPrec 

- 

length  precision  flag 

WPrec 

- 

weight  precision  flag 

LOrder 

- 

order  of  longl  presentation 

BhdXmin 

_ 

longl  location  (X)  of  aft-most  station  compartment 

BhdXmax 

- 

longl  location  (X)  of  fwd-most  station  compartment 

BhdNSTA 

- 

no.  of  stations  for  compartment  interpolation 

CompXoffi 

- 

longl  loc.  of  each  comp  station  i 

BhdZmin 

_ 

location  of  bhd  to  port 

BhdBoundType 

- 

flag  for  port  bhd 

BhdBoundSTR 

- 

name  of  port  bhd  file  name 

BhdZmax 

_ 

location  of  bhd  to  stbd 

BhdBoundType 

- 

flag  for  stbd  bhd 

BhdBoundSTR 

- 

name  of  stbd  bhd  file  name 

BhdYmin 

_ 

location  of  lower  deck 

BhdBoundType 

- 

flag  for  lower  deck 

BhdBoundSTR 

- 

name  of  lower  deck  file  name 

BhdYmax 

location  of  upper  deck 

BhdBoundType 

- 

flag  for  upper  deck 

BhdBoundSTR 

- 

name  of  upper  deck  file  name 

BhdGSpace 

_ 

girth  spacing  between  interpolation  points 

BhdTol 

- 

max.  tolerance  used  to  eliminating  points 

BhdInterpRule 

- 

interpolation  rule 

SphereNS 

- 

no.  of  stations  for  sphere 

SphereRadius 

- 

radius  of  sphere 

SphereXLoc 

- 

longl  (X)  location  of  center  of  sphere 

Sphere  YLoc 

- 

vertical  (Y)  location  of  center  of  sphere 

SphereZLoc 

- 

transverse  (Z)  location  of  center  of  sphere 

SphereTopBot 

- 

flag  (full  /  above  plane  /  below  plane) 

SpherePlaneLoc 

- 

location  of  point  on  plane  for  location 

SpherePlaneAngle 

- 

angle  of  plane  about  horizontal  plane 

C.3  Ship  Data  File  (.SDA) 

The  (.SDA)  file  contains  the  ship  data  for  the  HECSALV  software.  All  data  is  stored  in  metric 
units  (M.Tons  -  meters).  All  longitudinal  distances  are  referenced  about  amidships. 
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Class 

ship  class 

Ship 

- 

name  of  ship 

LBP 

- 

length  between  perpendiculars 

Beam 

- 

molded  beam 

Depth 

- 

molded  depth 

SLL 

- 

summer  loadline  draft 

LOA 

- 

length  over  all 

Unit 

unit  flag  0=metric  l=British 

LPrec 

- 

length  precision  flag 

WPrec 

- 

weight  precision  flag 

LRF 

- 

longl  reference  flag  0=amidship  1=AP  2 

LOrder 

- 

order  of  longl  presentation 

Yard 

_ 

yard  and  hull  no. 

Heel 

- 

heel  optional  flag 

NHydro 

- 

no.  of  drafts  in  hydrostatics  table 

ChgKM 

- 

no.  of  change  with  trim  KM  curves 

NStaBJ 

no.  of  stations  in  bonjean  tables 

NwlBJ 

no.  of  waterlines  in  bonjean  tables 

NAng 

- 

no.  of  angles  in  GZ  tables 

NDisp 

- 

no.  of  displacements  in  GZ  tables 

NStr 

- 

no.  of  strength  read-out  points 

SEA 

- 

flag  for  at  sea  and  in  harbor  data 

F.StrOpt 

longl  strength  flag 

PDia 

- 

propeller  diameter 

PCL 

- 

height  of  shaft  centerline  above  baseline 

MOLD 

- 

flag  for  molded  vs  keel  drafts 

NGrain 

- 

grain  stability  flag 

NGr  Allow 

- 

no.  of  grain  stability  allowable  values 

NGMRQdraft  -  no.  of  drafts  for  required  GM  data 

F.PropImm  -  propeller  immersion  formula  flag 

NVarPts  -  no.  of  volumes  for  variable  VCG/FS  data 

NGMRQ  -  no.  of  required  GM  curves 

NLsDistr  -  no.  of  points  of  lightship  weight  distr.  curve 

NWtBlock  -  no.  of  blocks  of  weight  for  lightship  weight  distr 


Shipl 

Ship2 

Ship3 

Ship4 

Ship5 

Ship6 

Ship? 

ShipS 

Ship9 

ShiplO 


lightship  weight 

lightship  vcg 

lightship  leg 

lightship  teg 

lightship  not  used 

lightship  fixed  constant  weight 

lightship  fixed  constant  vcg 

lightship  fixed  constant  leg 

lightship  fixed  constant  teg 

lightship  fixed  constant  free  surface  moment 


DMarkl 


longl  location  of  aft  marks 
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DMark2 

- 

height  of  aft  marks  at  location  DMarkl 

DMark3 

- 

longl  location  of  midship  marks 

DMark4 

- 

height  of  midhsips  marks  at  location  DMark3 

DMark5 

- 

longl  location  of  fwd  marks 

DMark6 

- 

height  of  fwd  marks  at  location  DMark5 

DMarkxy 

- 

longl  and  height  locaiton  for  non-vertical  marks 

DragAtMarks 

- 

vertical  offset  of  aft,  midships,  fwd  marks 

NGroup 

- 

max.  no.  of  tank  and  cargo  groups  in  SDA  file 

NCi 

- 

pointer  to  last  tank  in  group  i 

Ni 

- 

name  for  group  i 

ContLen 

- 

string  describing  applicable  container  lengths 

VisLocationll 

_ 

longl  location  of  helmsman 

VisLocationl2 

- 

vertical  location  of  helmsman 

VisLocation21 

- 

longl  location  of  obstruction  to  sight 

VisLocation22  . 

- 

vertical  location  of  obstruction  to  sight 

VisLocationSl 

- 

longl  location  of  bow  at  main  deck 

VisLocation32 

- 

vertical  location  of  bow  at  main  deck 

VisLocationl 

- 

reqd  visibility  in  distance  fwd  of  FP 

VisLocation2 

- 

reqd  visibility  in  no.  of  ship  lengthsn 

VisLocation3 

- 

assumed  length  of  ship  for  visibility  check 

Gi 

- 

density  of  fluid  for  group  i 

TkStr 

tank  name  for  tank  i 

TKShortStr 

'  - 

short  tank  name  for  tank  i 

Ci 

- 

default  weight  to  be  allocated  to  tank  i 

TKil 

- 

volume  of  tank  i 

TKi2 

- 

vcg  of  tank  i 

TKi3 

- 

leg  of  tank  i 

TKi4 

- 

teg  of  tank  i 

TKi5 

slack  free  surface  inertia  of  tank  i 

TKi6 

- 

98%-5deg  free  surface  inertia  of  tank  i 

TKi7 

- 

aft  tank  boundary  of  tank  i 

TKi8 

- 

fwd  tank  boundary  of  tank  i 

SGi 

- 

default  density  of  fluid  for  tank  i 

FRi 

_ 

descriptor  for  strength  read-out  point  i 

XFRi 

- 

longl  location  of  strength  read-out  point  i 

SLSi 

- 

weight  of  lightship  and  fixed  constant  aft  of  XFRi 

MLSi 

- 

moment  of  lightship  and  fixed  constant  aft  of  XFRi 

Allow  li 

_ 

at  sea  allowable  shear  force  at  read-out  point  i 

Allow2i 

- 

at  sea  allowable  hogging  moment  at  read-out  point  i 

Allow3i 

- 

at  sea  allowable  sagging  momenta!  read-out  point  i 

Allow4i 

- 

in  harbor  allowable  shear  force  at  read-out  point  i 

Allow5i 

- 

in  harbor  allowable  hogging  moment  at  read-out  point  i 
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Allow6i 

SMPropil 

SMPropi2 

SMPropi3 

SMPropi4 

SMPropil 

SMPropi2 

SMPropi3 

SMPropi4 

Hydroil 

Hydroi2 

Hydroi3 

Hydroi4 

Hydroi5 

HydroiG 

ChgKMTrimi 

ChgKMi 

XBJi 

DraftBJi 

BJji 

Angi 

Dispi 

DFldi 

GZij 

GMDescj 

GmRQij 

GMRQdraft 

NVaril 

NVari2 

PVolj 

PVCGj 

PLCGj 

PTCGj 

PFSj 

F. Material 
Mat  Name 
Emodulus 
MaxStressT 
MaxStressC 
U.  Stress 


in  harbor  allowable  sagging  moment  at  read-out  point  i 

hull  girder  inertia  (horz.  axis) 
section  modulus  to  deck  (horz.  eocis) 
section  modulus  to  keel  (horz.  axis) 
shear  area  (horz.  axis) 

hull  girder  inertia  (vert,  axis) 
section  modulus  to  deck  (vert,  axis) 
section  modulus  to  keel  (vert,  axis) 
shear  area  (vert,  axis) 

Icf  draft 

displacement 

KMt 

LCB  (m-MS) 

LCF  (m-MS) 

MTlm  (m-MT) 

trim  for  column  i  in  chang  in  KMt  with  trim 

change  in  KMt  for  trim  ChgKMTrimi  and  draft  Hydroil 

longl  locationof  station  i  in  bonjean  tables 

draft  i  in  bonjean  table 

bonjean  area  at  station  j  and  draft  i 

angles  indegrees  for  gz  table 

displacements  for  gz  tables 
downflooding  angle  corresponding  to  Dispi 
MS  value  for  Dispi  and  Angj 

description  of  required  gm  curve  j 

required  gm  value  for  curve  j  and  draft  Hydroil 

drafts  corrseponding  to  reqd  gm  values 

pointer  to  1st  variable  vcg/fs  data  for  tank  i 

pointer  to  last  variable  vcg/fs  data  for  tank  i 

volumes  in  variable  table 

vcg’s  in  variable  table 

leg’s  in  variable  table 

teg’s  in  variable  table 

free  surface  inertias  in  variable  table 

flag  for  type  of  steel,  alum,  etc 
material  name 
modulus  of  elasticity 
yield  stress  (tensile  flange) 
yield  stress  (compression  flange) 
stress  unit  flag 
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LsWtil 

- 

longl  location  of  pt  i  of  lightship  wt  distr  curve 

LsWti2 

- 

weight  ordinate  of  pt  i  on  lightship  wt  distr  curve 

WtBlockil 

- 

weight  in  block  i 

WtBlocki2 

- 

leg  of  weight  block  i 

WtBlocki3 

- 

aft  bound  of  weight  block  i 

WtBlockid 

- 

fwd  bound  of  weight  block  i 

User 

- 

user  name  or  initials 

Prj 

- 

project  no. 

Des 

- 

Description  of  project 

Udate 

- 

date  entered 

Rev 

” 

revision  no. 

C.4  Compartment  Access  Offset  Data  File  (.CML) 

The  (.CML)  file  contains  the  compartment  access  offset  data  for  the  HECSALV  software.  All 
data  is  stored  in  metric  units  (M.Tons  -  meters).  All  longitudinal  distances  are  referenced  about 


amidships. 

TNoComp 

_ 

total  no.  of  compartments 

TNProfile 

- 

no.  of  points  on  profile  view  for  all  empts 

TNPlan 

- 

no.  of  points  on  plan  view  for  all  empts 

TNDfld 

- 

no.  of  downflooding  points  for  all  compts 

FListStri 

_ 

file  name  for  empt  i 

MIDi 

- 

name  of  empt  i 

TCPerm 

- 

compartment  permeability  for  empt  i 

TCVol 

- 

100%  volume  for  compartment  i 

NTProfi 

- 

no.  of  points  on  profile  view  of  empt  i 

NTPlan 

- 

no.  of  points  on  plan  view  of  empt  i 

NTDfldi 

- 

no.  of  downfiooding  points  of  empt  i 

TOffProfil 

- 

longl  (X)  location  of  profile  point  i 

T0ffProfi2 

- 

transverse  (Y)  location  of  profile  point  i 

TOffPlanil 

_ 

longl  (X)  location  of  plan  point  i 

TOffPlani2 

- 

transverse  (Z)  location  of  plan  point  i 

TOfFDfldil 

_ 

longl  (X)  location  of  dfld  point  i 

TOffDfldi2 

- 

transverse  (Y)  location  of  dfld  point  i 

TOffDfidiS 

- 

transverse  (Z)  location  of  dfld  point  i 

Ship 

_ 

name  of  ship 

Class 

- 

ship  cl8iss 

LBP 

- 

length  between  perpendiculars 

Beam 

- 

molded  beam 

Depth 

- 

molded  depth 

User 

_ 

user  name  or  initials 

Prj 

- 

project  no. 
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Des 

Udate 

Rev 


Description  of  project 
date  entered 
revision  no. 
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Appendix  D 

VMS  -  Required  Input 
Information 

D.l  Vessel  Table 

The  Vessel  Table  contains  the  following  information: 


Vessel  Name 

UCA 

Long  Name 

LR# 

Summer  DWT 

Winter  DWT 

Tropic  DWT 

Light  Ship 

Crew  Stores 

LOA 

Beam 

Summer  Draft 

TPI 

Cargo  Capacity 

Suez  Net.  Ton/ 

Fuel  Capacity 

Panama  Net.  Ton. 

Engine  Type 

RPM 

RPM  Multiplier 

SHF 

Power  Constant 

Power 

Propeller 

Full  Speed  Loaded 

Min.  Speed  Ballast 

Full  Speed  Ballast 

Min.  Speed  Loaded 

M.E.  Fuel  at  Sea 

Aux.  Fuel  at  Sea 

M.E.  Fuel  in  Port 

Aux.  Fuel  in  Port 

M.E.  Lubes 

Fuel  to  Discharge 

Fuel  to  Heat 

Fuel  Loaded  Factor 

Fuel  Ballast  Factor 

Yard 

Year  Built 

D.2  Fuel  Cost  Initialization 

The  Fuel  Cost  Initialization  information  has  to  be  entered  once  only  for  each  vessel  on  program 
installation: 

Fuel  Capacity  Fuel  Cost 

Diesel  Capacity  Diesel  Cost 

Lube  Capacity  Lube  Cost 

D.3  Vessel  Daily  Cost 

The  Vessel  Daily  Cost  information  has  to  be  entered  once  per  year  for  each  vessel  and  is  needed 
for  yoyage  economics  calculations.  All  costs  are  daily  costs. 
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Vessel  Year 

Crew  Labor  Stores,  Tools  and  Feeding  Miscellaneous 

Incremental  Overhead  Operating  Insurance  Voyage  Maintenance  and  Repair 

Periodic  Overhaul 


D.4  Voyage  Itinerary 

The  Voyage  Itinerary  information  lists  the  port  of  departure  and  point  of  arrival  and  all  interme¬ 
diate  ports.  For  each  port  the  terminal,  the  activity  and  the  date  and  time  are  listed.  Date  and 
time  information  is  used  as  an  Estimated  Time  of  Arrival  for  the  Noon.  Position  Reports. 


Vessel  Voyage  Number 

To/From  Flag  Port  Terminal 

Activity  Bunker  Date 

Time 


D.5  Cargo  Orders 

The  Cargo  Orders  uses  information  from  the  Voyage  Itinerary  table  to  determine  the  load  and 
discharge  ports.  For  the  discharge  ports  cargo  information  is  entered. 


Vessel 

Voyage  Number 

Activity 

Load  Port 

Terminal 

Grade 

Discharge  Port 

Terminal 

Consignee 

Basis 

Quantity 

Rate 

D.6  Bunker  Orders 

The  Bunker  Orders  uses  information  from  the  Voyage  Itinerary  table  to  determine  the  bunker 
ports.  For  these  ports  bunker  information  is  entered. 


Vessel 

Port 

Diesel  Quantity 
Fuel  Quantity 
Lube  Quantity 


Voyage  Number 
Terminal 
Diesel  Rate 
Fuel  Rate 
Lube  Rate 


Activity 

Diesel  Cost 
Fuel  Cost 
Lube  Cost 


D.7  Charter  Party  Information 

The  Charter  Party  table  specifies  information  needed  for  laytime  and  demurrage  calculations. 


Vessel 

Allowed  Time 
Charter  Party  Date 


Voyage  Number 
Durrage  Daily  Rate 
Laydays  Commence 


Charterer 

Charter  Party  Form 
Laydays  Cancel 
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D.8  Port  Costs  and  Canal  Fees 

Both  port  costs  and  canal  fees  are  entered  in  this  table. 


Vessel  Voyage  Number 

Port  OCode  Cost 

Canal  OCode  Fee 


D.9  Waypoint  Chain 

The  Waypoint  Chain  lists  for  a  specific  route  defined  by  departure  and  destination  port  the  sequence 
of  waypoints.  Defined  Waypint  chains  can  be  recalled  for  use  in  the  Current  Sea  Leg  table. 

WP  Chain  ID  Description 

Seq  #  Chart  #  Latitude 

Longitude  Track  Course 

Distance 

D.IO  Current  Sea  Leg 

For  a  given  voyage,  the  Current  Sea  Leg  information  is  based  on  a  defined  waypoint  chain. 


Voyage 

From 

To 

WP  Chain 

WP  # 

Chart  # 

Latitude 

Longitude 

Track 

Course 

Distance 

D.ll  Noon  Position  Report 

The  Noon  Position  Report 

is  completed  daily  and  at  stand-by  arrival. 

Vessel 

From 

To 

Voyage  Number 

Date 

Time 

Zone 

OP  Code 

Activity 

Latitude 

Longitude 

Daily  Miles 

Deck  Log 

Elapsed  Hours 

Course 

Detention  Time 

Detention  Miles 

Beaufort 

Wind  Direction 

Wind  Angle 

Swell  Height 

Swell  Direction 

Draft 

Displacement 

Trim 

Sea  Temperature 

Daily  Speed 

Daily  RPM 

Daily  Slip 

Daily  Eng/Mls 

Total  Dist. 

Dist  Trav. 

Dist.  to  go 

ETA 

Total  Eng.  Miles 

AVG  RPM 

AVG  Slip 

AVG  Speed 

Tot.  Time 

Tot.  Det.  Time 

Tot.  Det.  Miles 

REQ.  Speed 

Cargo  Heat 

Steam  on  Deck 

Cargo  Pump 

Daily  M.E.  HFO 

Daily  M.E.  DO 

Daily  M.E.  CO 

Daily  Aux  HFO 

Daily  Aux  DO 

Daily  Aux  CO 

Total  M.E.  HFO 

Total  M.E.  DO 

Total  M.E.  CO 

Total  Aux  HFO 

Total  Aux  DO 

Total  Aux  CO 

Remain.  M.E.  HFO 

Remain.  M.E.  DO 

Remain.  M.E.  CO 

Remain.  Aux  HFO 

Remain.  Aux  DO 

Remain.  Aux  CO 
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D.12  Engine  Log 

This  log  is  completed  daily  at  noon. 


Voyage  Number 
Date 

ME  FO  Meter 
Cyl  Oil  Meter 
M.E.  Daily  Cons. 

Cyl  Oil  Daily  Cons. 
HFO  Meter  ROB 
HFO  CargoMax  ROB 
RPM 

Engine  Miles 
CYl  SFC 
DO  Meter  Factor 


Activity 

Time 

BLR  FO  Meter 
ME  Counter 
Boiler  Daily  Cons. 

DO  Meter  ROB 
DO  CargoMax  ROB 
Elapsed  Time 
Slip  per  day 
ME  Meter  Factor 
Cyl  Meter  Factor 


OP  Code 
Time  Zone 
DG  Meter 
HP 

D.G.  Daily  Cons. 

CO  Meter  ROB 
CO  CargoMax  ROB 
OBS  Daily  Miles 
ME  SFC 

BLR  Meter  Factor 


D.13  Maneuvering  and  Port  Fuel  Consumption 

The  Maneuvering  and  Port  Fuel  Consumption  distinguishes  between  port  and  maneuvering  fuel 
consumption.  The  consumption  for  different  activities  is  listed. 


Vessel 

Man.  OP  Code 
Man.  Elapsed  Time 
Man.  CO 
Port  OP  Code 
Port  HFO 


Voyage  Number 
Man.  Date 
Man.  HFO 

Port  Date 
Port  DO 


Voyage  Description 
Man.  Miles 
Man.  DO 

Port  Elapsed  Time 
Port  CO 


D.14  Port  Activity 

The  Port  Activity  contains  a  detailed  list  of  the  individual  activities  while  in  port  including  the 
elapsed  time  and  laytime  calculations. 


Vessel 
Port 
Activity 
Elapsed  Time 
Ship  Delays 


Voyage  Number 

Terminal 

Date 

Laytime  Start 
Terminal  Delays 


OP  Code 

Berth 

Time 

Laytime  End 


D.15  CargoMax  to  Cargo  Upload 

The  cargo  tables  are  updated  using  the  CargoMax  information. 


Vessel 

Old  Fuel  GSV 
New  Fuel  GSV 
Old  Diesel  GSV 
New  Diesel  GSV 
Old  FresRGSV 


Voyage  Number 
Old  Fuel  TOV 
New  Fuel  TOV 
Old  Diesel  TOV 
New  Diesel  TOV 
Old  Fresh  TOV 


Port 

Old  Fuel  FW 
New  Feul  FW 
Old  Diesel  FW 
New  Diesel  FW 
Old  Fresh  FW 
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New  Fresh  GSV 
Old  Balstp  GSV 
New  Balstp  GSV 
Old  Misc  GSV 
New  Misc  GSV 


New  Fresh  TOV 
Old  Balstp  TOV 
New  Balstp  TOV 
Old  Misc  TOV 
New  Misc  TOV 


New  Fresh  FW 
Old  Balstp  FW 
New  Balstp  FW 
Old  Misc  FW 
New  Misc  FW 


D.16  Shore  /  Bill  of  Loading  Cargo  Figures 

The  bill  of  loading  figures  are  required  for  the  deadfreight  calculations. 


Vessel 

Lightering 

Grade 

NSV  60degF 
TCV  60degF 


Voyage  Number 
Port 

Consignee 
S&W 
Net  Tons 


OpCode 

Terminal 

API 

GSV  60deg  F 
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Appendix  E 

SSIIS  Prototype  -  Documentation 


As  part  of  the  SSIIS  database  system  prototype,  data  input  screens  have  been  developed  for  all 
tables  contained  in  the  datastructure.  These  input  screens  are  organized  in  four  different  sub¬ 
menus: 

•  System  Data 

•  Vessel  Data 

•  Inspection  Data 

•  Operations  Data 

In  the  following  sections  the  individual  data  screens  are  described  including  a  graphical  repre¬ 
sentation  of  each  implemented  data  entry  screen. 


E.l  System  Data  Entry 

The  System  data  entry  selection  screen  is  shown  in  Fig.  (7.4).  It  contains  eight  menu  choices, 
which  are  described  in  the  following  sections. 

E.1.1  Cargo 

The  Cargo  data  entry  screen  is  shown  in  Fig.  (E.l).  Different  Cargo  types  can  be  entered  in  this 
screen. 

E.1.2  Cause 

The  Cause  data  entry  screen  is  shown  in  Fig.  (E.2).  Different  causes  for  failures  can  be  entered 
in  this  screen  including  a  long  definition  of  the  failure  mechanisms. 

E.l. 3  Classification 

The  Classification  data  entry  screen  is  shown  in  Fig.  (E.3).  Different  classification  societies  are 
entered  in  this  screen  including  the  name,  an  abbreviation  and  the  country. 

E.l. 4  Company 

The  Company  data  entry  screen  is  shown  in  Fig.  (E.4).  Different  owners  and  operators  are  entered 
in  this  screen  including  the  name  and  the  complete  address.  The  information  in  this  table  is  used 
to  identify  both  owners  and  operators. 
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E.1.5  Repair 

The  Repair  data  entry  screen  is  shown  in  Fig.  (E.5).  Different  repair  solutions  are  entered  includ¬ 
ing  a  long  description  of  the  repair. 

E.1.6  Shipyard 

The  Shipyard  data  entry  screen  is  shown  in  Fig.  (E.6).  The  complete  name  and  address  for 
different  shipyards  is  entered  in  this  data  entry  screen. 

E.1.7  Steel 

The  Steel  data  entry  screen  is  shown  in  Fig.  (E.7)  .  Different  steel  types  can  be  entered  in  this 
screen. 

E.1.8  Corrosion  Protection 

The  Corrosion  Protection  data  entry  screen  is  shown  in  Fig.  (E.8).  Different  corrosion  protection 
systems  can  be  defined  including  a  long  description  of  the  procedure. 


E.2  Vessel  Data  Entry 

The  Vessel  data  entry  selection  screen  is  shown  in  Fig.  (7.5).  It  contains  four  menu  choices,  which 
are  described  in  the  following  sections. 

E.2.1  Vessel 

The  Vessel  data  entry  screen  is  shown  in  Fig.  (E.9).  Vessel  information  can  be  entered  in  this 
screen.  The  available  vessel  classes,  owner/operators,  classification  societies  and  shipyards  are 
listed.  This  ensures  that  only  valid  data  can  be  entered. 

E.2. 2  Class 

The  Class  data  entry  screen  is  shown  in  Fig.  (E.IO).  The  general  structural  configuration  is  entered 
in  this  screen  including  vessel  particulars. 

E.2.3  Tank 

The  Tank  data  entry  screen  is  shown  in  Fig.  (E.ll).  It  contains  the  general  tank  dimensions 
for  each  tank  of  a  specific  vessel  class  that  can  be  selected  from  a  list  of  available  classes.  The 
information  about  available  tank  numbers  is  also  provided  using  a  list  that  is  obtained  from  the 
TankJfo  table. 

E.2. 4  Tank  Number 

The  Tank  Number  data  entry  screen  is  shown  in  Fig.  (E.12).  It  contains  for  each  vessel  class  the 
possible  tank  numbers. 


E.3  Inspection  Data  Entry 

The  Inspection  data  entry  selection  screen  is  shown  in  Fig.  (7.6).  It  contains  six  menu  choices, 
which  are  described  in  the  following  sections. 
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E.3.1  Inspection 

The  Inspection  data  entry  screen  is  shown  in  Fig.  (E.13).  Inspection  information  is  listed  for  each 
vessel  of  a  specified  class  including  the  inspection  location,  the  inspection  company,  the  inspector 
and  the  date  of  the  inspection.  Location,  company,  vessel  and  class  information  is  provided  in  a 
list  format  to  allow  only  the  choice  of  available  data.  This  ensures  data  integrity. 

E.3.2  Inspection  Company 

The  Inspection  Company  data  entry  screen  is  shown  in  Fig.  (E.14).  It  allows  the  entry  of  the 
name  and  address  of  different  inspection  companies. 

E.3.3  Inspection  Location 

The  Inspection  Location  data  entry  screen  is  shown  in  Fig.  (E.15).  It  allows  the  entry  of  different 
inspection  locations. 

E.3.4  Corrosion 

The  Corrosion  data  entry  screen  is  shown  in  Fig.  (E.16).  Corrosion  data  is  entered  for  each 
inspection  of  an  individual  vessel  of  a  specified  class.  With  the  exception  of  the  actual  corrosion 
data  (thickness,  location)  all  information  is  entered  based  on  lists  of  available  data  to  ensure  data 
integrity. 

E.3.5  Crack 

The  Crack  data  entry  screen  is  shown  in  Fig.  (E.17).  Crack  data  is  entered  for  each  inspection  of 
an  individual  vessel  of  a  specified  class.  With  the  exception  of  the  actual  crack  information  (length, 
location)  all  information  is  entered  baised  on  lists  of  available  data  to  ensure  data  integrity. 


E.3.6  Crack  Class 

The  Crack  Class  data  entry  screen  is  shown  in  Fig.  (E.18).  The  definitions  of  different  crack 
classes  are  entered  in  this  screen. 


E.4  Operations  Data  Entry 

The  Operations  data  entry  selection  screen  is  shown  in  Fig.  (7.7).  It  contains  three  menu  choices, 
which  are  described  in  the  following  sections. 

E.4.1  Leg 

The  Leg  data  entry  screen  is  shown  in  Fig.  (E.19).  For  each  voyage  leg  for  a  particular  vessel  the 
departure  and  destination  ports  and  dates  are  entered.  In  addition,  cargo  and  ballast  conditions 
are  included. 

E.4. 2  Monitoring 

The  Monitoring  data  entry  screen  has  not  been  implemented.  Additional  research  is  needed  to 
define  the  data  structure  for  the  monitoring  module. 
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E.4.3  Ports 


The  Ports  data  entry  screen  is  shown  in  Fig.  (E.20).  It  allows  the  entry  of  the  port  name  and  the 
geographic  location  (longitude  and  latitude)  and  the  country. 
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Figure  E.2;  Cause  Entry  Screen 


165 


Figure  E.3:  Classification  Entry  Screen 


Figure  E.4:  Company  Entry  Screen 
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Figure  E.5:  Repair  Entry  Screen 


Figure  E.6:  Shipyard  Entry  Screen 


Figure  E.7:  Steel  Entry  Screen 


Figure  E.8:  Corrosion  Protection  Entry  Screen 
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Figure  E.9:  Vessel  Entry  Screen 


Figure  E.IO;  Class  Entry  Screen 
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Figure  E.13:  Inspection  Entry  Screen 


Figure  E.15:  Inspection  Location  Entry  Screen 


Figure  E.16:  Corrosion  Entry  Screen 
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Figure  E.17:  Crack  Entry  Screen 


i  I  P««  if  C'W  I  C»o«*  I  I  fafee#  Class  : 


"Mi 


Figure  E.18:  Crack  Class  Entry  Screen 


Figure  E.19:  Leg  Entry  Screen 
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Appendix  F 


Addresses  of  Software  Developers 


In  the  following,  for  each  of  the  programs  (database  and  applications)  that  have  been  documented 
in  this  report,  a  contact  address  is  listed. 

F.l  Databases 

CATSIR  Chevron  Shipping  Company 

555  Market  Street 
San  Francisco,  CA  94105 
(415)  894-7700 

OCEANEERING  /  SOLUS  SCHALL 
1441  Park  Ten  Boulevard 
Houston,  TX  77218 

(713)  579-0627 

HFDB  ARCO  Marine 

300  Oceangate 

Long  Beach,  CA,  90902-4341 

(310)  590-4527 

FracTrac  MCA  Engineers,  Inc. 

2960  Airway  Avenue,  #A-103 
Costa  Mesa,  CA  92626 

(714)  662-500 

SID  MIL  Systems  Engineering  Inc. 

700-1600  Carling  Avenue 
Ottawa,  Ontario  KIZ  8R7 
CANADA 
(613)  722-2247 

SIMS  University  of  California  at  Berkeley 

Department  of  Naval  Architecture  k  Offshore  Engineering 
202  Naval  Architecture  Bldg. 

Berkeley,  CA  94720 
(510)  642-5464 
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F.2  Application  Programs 

HECSALV  Herbert  Engineering  Corp. 

98  Battery  Street,  Suite  500 
San  Francisco,  CA  94111 
(415)  296-9700 

CARGOMAX  Herbert  Engineering  Corp. 

98  Battery  Street,  Suite  500 
San  Francisco,  CA  94111 
(415)  296-9700 

TACTICS  American  President  Lines  (APL) 

nil  Broadway 
Oakland,  CA  94607 
(510)  272-8000 

Ship  Research  Incorporated 
455  17th  Street,  Suite  301 
Oakland,  CA  94612 

VMS  Chevron  Shipping  Company 

555  Market  Street 
San  Francisco,  CA  94105 
(415)  894-7700 
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